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Abstract 


A  quality  of  service  (QoS)  management  framework  for  systems  is  presented  that 
satisfies  application  needs  along  multiple  dimensions  such  as  timeliness,  reliability, 
cryptographic  security  and  other  application-specific  quality  requirements.  In  this 
model,  end  users’  quality  preferences  are  taken  into  account  when  system  resources 
are  apportioned  across  multiple  applications  such  that'  the  net  system  utility  accrued 
to  the  end-users  is  maximized.  The  framework  facilitates  QoS  tradeoff  through  a 
semantically  rich  (in  terms  of  expressiveness  and  customizability)  QoS  specification 
interface  that  enables  the  end  users  to  give  guidance  on  the  qualities  they  care  about 
and  the  tradeoffs  they  are  willing  to  make  under  potential  resource  shortages.  The 
interface  also  allows  the  user  or  system  administrator  to  define  fine-grained  service 
requests  easily  for  multi-dimensional  complex  QoS  provisioning.  Furthermore,  by 
introducing  the  abstraction  of  Quality  Index,  which  maps  qualities  to  indices  in  a  uni¬ 
form  way,  and  by  the  mathematical  modeling  of  QoS  Tradeoff  and  Resource  Tradeoff, 
we  transform  the  QoS  management  problem  into  a  combinatorial  optimization  which 
ultimately  enables  us  to  quantitatively  measure  QoS,  and  to  anal3d;ically  plan  and 
allocate  resources. 

A  series  of  optimization  algorithms  is  developed  that  tackle  the  QoS  management 
problem  which  is  provably  NP-hard.  The  first  set  of  algorithms  treats  the  problem 
of  maximizing  system  utility  by  allocating  a  single  finite  resource  to  satisfy  the  QoS 
requirements  of  multiple  applications  along  multiple  QoS  dimensions.  Two  near- 
optimal  algorithms  are  developed  to  solve  this  problem.  The  first  yields  an  allocation 
within  a  known  distance  from  the  optimal  solution,  and  the  second  yields  an  allocation 
whose  distance  bound  from  the  optimal  solution  can  be  explicitly  controlled  by  a 
QoS  manager.  We  compare  the  run-times  of  these  near-optimal  algorithms  and  their 
solution  quality  relative  to  the  optimal  allocation,  which  in  turn  is  computed  using 
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dynamic  programming. 

The  second  set  of  algorithms  deals  with  apportioning  multiple  finite  resources 
to  satisfy  the  QoS  needs  of  multiple  applications  along  multiple  QoS  dimensions. 
Three  strategies  are  evaluated  and  compared  First,  dynamic  programming  and  integer 
programming  with  branch-and-bound  compute  optimal  solutions  to  this  problem  but 
exhibit  very  high  running  times.  Then  the  integer  programming  approach  is  adapt 
to  yield  near-optimal  results  with  faster  running  times.  Finally,  an  approximation 
algorithm  based  on  an  extended  local  search  technique  is  presented  that  is  less  than  a 
few  percent  from  the  optimal  solution  but  which  is  more  than  two  orders  of  magnitude 
faster  than  the  optimal  scheme  of  dynamic  programming.  Perhaps  more  significantly, 
the  local  search  technique  turns  out  to  be  very  scalable  and  robust  as  the  number  of 
resources  under  management  increases.  These  detailed  evaluations  provide  practical 
insight  into  which  of  these  algorithms  can  be  used  online  in  real-time  systems. 
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Chapter  1 
Introduction 


1.1  Motivation 

Quality  of  Service  (QoS)  control  is  receiving  widespread  attention  in  computer  net¬ 
work  and  real-time  multimedia  system  research  as  well  as  commercial  markets.  Typ¬ 
ically,  service  characteristics  in  existing  multimedia  and  networked  systems  are  fixed 
when  systems  are  built,  therefore  they  often  do  not  give  users  any  real  influence  over 
the  QoS  they  can  obtain.  On  the  other  hand,  multimedia  applications  and  their  users 
can  differ  enormously  in  their  requirements  for  service  quality  and  the  resources  avail¬ 
able  to  them  at  the  time  of  application  use.  Therefore,  there  is  an  increasing  need  for 
customizable  services  that  can  be  tailored  for  the  end  users’  specific  requirements. 

In  the  meantime,  new  and  improved  systems  such  as  the  one  proposed  by  the 
Amaranth  project  at  Carnegie  Mellon  University  [59]  are  placing  more  and  more 
complex  demands  on  the  quality  of  service  that  are  reflected  in  multiple  criteria  over 
multiple  quality  dimensions.  These  QoS  requirements  can  be  objective  in  some  aspects 
and  subjective  in  others.  Moreover,  because  of  the  manifold  and  subjective  nature  of 
user  quality  demands,  it  is  very  hard  to  measure  whether  the  provided  quality  fulfills 
the  stated  demands  without  guidance  and  input  from  end  clients. 

One  issue  is  QoS  Tradeoff  where  a  user  of  an  application  might  want  to  emphasize 
certain  aspects  of  quality,  but  not  necessarily  others.  Users  might  tolerate  different 
levels  of  service,  or  could  be  satisfied  with  different  quality  combination  choices,  but 
the  available  system  resources  might  only  be  able  to  accommodate  some  choices  but 
not  others.  In  situations  where  a  user  is  able  to  identify  a  number  of  desirable  objective 
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qualities  and  rate  them  (subjectively),  the  system  should  be  able  to  reconcile  different 
demands  to  maximize  the  user’s  preference  and  to  make  the  most  effective  use  of  the 
system.  So  it  is  important  for  a  system  to  provide  a  large  variety  of  service  qualities 
and  to  accommodate  specific  user  quality  requirements  and  deliver  as  good  service  as 
it  can  from  the  users’  perspective. 

An  issue  related  to  QoS  tradeoff  is  Resource  Tradeoff.  In  this  case,  the  tradeoff 
refers  to  reconciling  or  balancing  competing  resource  demands.  Resource  tradeoff 
is  often  transparent  to  the  user  but  can  be  of  great  help  in  accommodating  user  re¬ 
quirements  including  QoS  tradeoff,  especially  when  the  availability  of  several  different 
resources  is  not  balanced.  It  arises  when  an  application  is  able  to  use  an  excess  of 
one  resource,  say  CPU  power  or  cache,  to  lower  its  demands  on  another,  say  network 
bandwidth,  while  maintaining  the  same,  or  similar,  level  of  QoS.  For  example: 

•  Video  conferencing  systems  often  use  compression  schemes  that  are  effective, 
but  computationally  intensive,  to  trade  CPU  time  for  network  bandwidth.  If 
the  bandwidth  is  congested  on  some  intermediate  links  (which  is  often  the  case), 
this  benefits  the  system  as  a  whole. 

•  In  the  case  of  a  mobile  client  with  limited  CPU  and  memory  capacity  but  suf¬ 
ficient  link  speed  with  a  nearby  intermediate  powerful  server,  computationally 
expensive  speech  recognition,  silence  detection  and  cancellation,  and  video  com¬ 
pression  could  be  carried  out  on  the  nearby  server. 

•  For  proxy  servers  which  act  as  transcoders/transceivers  besides  caching  data, 
the  proxy  servers  can  distill  data  for  low  bandwidth  clients  (when  both  server 
and  client  have  fast  CPU,  memory  and  disk  bandwidth,  but  the  network  link 
speed  in  between  is  limited). 

Consider  a  video-conferencing  application.  The  audio  streams  in  this  application 
have  multiple  QoS  characteristics:  the  sampling  rate  of  the  audio  data,  the  resolution 
(number  of  bits)  of  each  audio  sample,  and  the  end-to-end  latency  of  the  audio  stream. 
Similarly,  the  video  streams  must  deal  with  multiple  QoS  dimensions:  the  video 
frame  rate,  the  size  of  the  video  window,  the  number  of  bits  per  pixel  and  so  on. 
Given  an  operating  point  along  each  of  these  QoS  dimensions,  the  application  requires 
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processing  and  network  bandwidth  resources  at  the  application  end-hosts  and  all 
intermediate  links  that  the  audio/video  streams  traverse. 

We  envision  an  environment  where  many  such  time-critical,  real-time  and  non- 
real-time  applications  each  with  multiple  QoS  dimensions  co-exist  in  a  system  with  a 
set  of  finite  resources  under  management.  During  loaded  periods,  the  system  may  not 
have  sufficient  resources  to  deliver  the  maximum  quality  possible  to  every  application 
along  each  of  its  QoS  dimensions.  Hence,  decisions  must  be  made  by  the  underlying 
resource  manager  to  apportion  available  resources  to  these  applications  such  that  a 
global  objective  is  maximized. 

1.2  Related  Work 

Research  on  Quality  of  Service  for  multimedia  applications  has  gained  significant 
momentum  over  the  last  few  years.  Much  research  has  been  conducted  on  the  end- 
system  or  end-to-end  architectures  for  QoS  support  [12,  17,  6,  39,  40,  4,  36,  24,  8, 
60,  48,  26,  21],  and  much  more  is  on  link,  network  and  transport  layer  ([62,  61,  11, 
52,  55,  33,  54,  5]  to  name  a  few).  Most  of  this  research  has  been  focused  on  low-level 
system  mechanisms.  The  authors  consider  and  work  on  such  parameters  as  period, 
buffer  size,  jitter,  bandwidth  and  so  on.  While  these  issues  are  important  factors  for 
QoS  control,  we  believe  that  they  are  not  sufficient  for  the  ultimate  end-users  who 
experience  the  resulting  QoS. 

Research  on  adaptive  QoS  control  [57,  56,  35,  29,  41]  brings  us  a  step  closer  to  the 
QoS  support  from  a  user’s  perspective  by  providing  a  mechanism  in  an  application 
to  accommodate  potential  dynamic  changes  in  the  operating  environment.  But  these 
mechanisms  are  still  mainly  system-oriented  in  that  a  user  has  limited  influence  over 
the  quality  of  the  service  to  be  delivered  or  adapted. 

In  coping  with  the  shortage  of  QoS  support  from  an  end-user  point  of  view,  we 
proposed  a  basic  framework  [25,  30,  46]  that  enables  the  end  users  to  give  guidance 
on  the  qualities  they  care  about  and  the  tradeoffs  they  are  willing  to  make  under 
potential  resource  constraints.  Working  from  the  user’s  perspective  and  maximizing 
the  user  perceived  quality  or  utility  has  also  been  addressed  in  [19,  2,  3].  In  [19],  a 
user-centric  approach  is  taken,  where  a  user’s  preferences  are  considered  for  applica¬ 
tion  runtime  behavior  control  and  resource  allocation  planning.  Example  preferences 
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include  statements  that  a  video-phone  call  should  pause  a  movie  unless  it’s  being 
recorded  and  that  video  should  be  degraded  before  audio  when  all  desired  resources 
are  not  available.  These  are  useful  hints  for  high-level  QoS  control  and  resource  plan¬ 
ning,  but  are  inadequate  for  quantitatively  measuring  QoS,  or  analytically  planning 
and  allocating  resources. 

The  notion  of  using  utility  functions  to  represent  varying  satisfaction  with  QoS 
changes  is  certainly  not  new.  Jensen  et  al.  [18]  and  Locke  [32]  are  perhaps  among  the 
first  to  study  “value  functions”  to  represent  the  benefit  of  different  completion  times 
of  a  task.  Their  value  function  model  is  a  utility  function  along  the  latency  quality 
dimension  of  real-time  tasks.  Our  model  can  be  viewed  as  extending  this  notion  to 
include  quality  dimensions  other  than  timeliness.  The  imprecise  computation  model 
proposed  by  Liu  et  al.  [31]  considered  the  problem  of  optimally  allocating  CPU  cycles 
to  applications  which  must  satisfy  minimum  CPU  requirements,  but  can  produce 
better  results  with  additional  CPU  cycles.  The  frequency  of  each  application  remains 
constant,  while  the  computation  time  per  instance  of  an  application  can  be  varied. 
The  results  were  generally  assumed  to  improve  linearly  with  additional  resources.  The 
model  described  in  this  thesis  can  be  considered  to  be  a  generalization  of  the  above 
model  from  single  quality  dimension  to  multiple  QoS  dimension  optimization  with 
potential  QoS  tradeoffs,  and  from  single  resource  to  multiple  resource  allocation  with 
potential  resource  tradeoffs.  Applying  utility  model  for  QoS  control  is  also  studied 
in  [2,  22].  In  [2],  the  authors  propose  a  mechanisni  for  QoS  (re)negotiation  as  a  way 
to  ensure  graceful  degradation.  The  authors  suggest  that  a  user  should  be  able  to 
express,  in  his/her  service  requests,  the  spectrum  of  QoS  levels  the  user  can  accept 
from  the  provider,  as  well  as  the  perceived  utility  of  receiving  service  at  each  of  these 
levels.  A  similar  approach  is  taken  in  [22].  But  neither  of  the  authors  address  the 
resource  tradeoff  problem.  Also,  neither  has  developed  the  specification  method  and 
mechanism  to  facilitate  utility  data  acquisition.  We  will  return  to  [22]  in  Chapter  6 
for  more  related  work  and  comparisons. 

Interesting  research  have  been  conducted  in  [3]  and  [37,  20].  In  [3],  the  authors 
present  a  framework  for  the  construction  of  network-aware  applications.  The  basic 
idea  is  to  allow  an  application  to  adapt  to  its  network  environment,  e.g.  by  trading  off 
the  volume  (and  with  it  the  quality)  of  the  data  to  be  transfered  and  the  time  needed 
for  the  transfer.  Their  mechanism  coincides  with  one  of  our  schemes  for  implement- 
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ing  the  resource  tradeoff  (r  \=i  q).  The  model  defined  in  [30]  can  be  considered  a 
generalization  of  [3].  The  authors  in  [37]  thoroughly  explored  building  an  analytical 
framework  for  adaptive  terminal  10  service,  which  can  be  viewed  as  good  mechanism 
for  resource  tradeoff.  We  believe  that  their  work  can  operate  well  together  with  the 
work  presented  in  this  thesis. 


1.3  Approach 


Figure  1.1  gives  a  pictorial  view  of  our  QoS  management  optimization  system. 

The  QoS  architecture  [27]  we  consider  consists  of  a  QoS  specification  interface, 
a  quality  tradeoff  specification  model,  and  a  unified  QoS-based  admission  control 
and  resource  allocation  model.  The  QoS  specification  interface  allows  multiple  QoS 
requirements  to  be  specified,  and  is  semantically  rich  both  in  terms  of  expressiveness 
and  customizability.  Note  that  our  QoS  management  framework  is  translucent  in  a 
sense  that  some  aspects  are  made  visible  to  the  end-users  so  that  users  can  control  the 
delivered  QoS  parameters,  while  at  the  same  time  hiding  how  the  requested  delivery 
is  accomplished.  In  the  model,  end  users’  quality  preferences  are  elicited  when  system 
resources  are  apportioned  across  multiple  applications  such  that  the  net  utility  that 
accrues  to  the  end-users  is  maximized.  Specifically,  the  QoS  tradeoff  specification 
interface  allows  applications  and  users  to  assign  values  (utilities)  to  different  levels 
of  service  that  a  system  can  provide.  A  QoS  resource  manager,  taking  QoS  profiles 
and  resource  profiles  of  arriving  applications  as  its  inputs  and  exploring  fully  the  QoS 
tradeoffs  and  resource  tradeoffs,  makes  resource  allocations  to  these  applications  so  as 
to  maximize  the  global  utility  derived  by  these  systems.  Finally,  by  introducing  the 
abstraction  of  Quality  Index,  which  maps  qualities  to  indices  in  a  uniform  way,  and  by 
the  mathematical  modelling  of  QoS  Tradeoff  and  Resource  Tradeoff,  we  transform  the 
QoS  management  problem  into  combinatorial  optimization  which  ultimately  enables 
us  to  quantitatively  measure  QoS,  and  to  analytically  plan  and  allocate  resources. 
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Figure  1.1:  Input  and  Output  of  the  QoS  Management  Optimization  Module 

1.4  Organization  of  the  Dissertation 

The  rest  of  the  dissertation  is  organized  as  follows:  In  Chapter  2  we  formally  in¬ 
troduce  our  QoS  management  model.  We  start  the  chapter  with  example  quality 
dimensions.  We  then  introduce  the  abstraction  of  Quality  Index.  Then  QoS  Tradeoff 
and  Resource  Tradeoff  are  formally  modeled.  We  conclude  this  chapter  by  formulat¬ 
ing  our  QoS  management  problem  and  demontrating  its  power  in  terms  of  generality 
and  expressiveness.  In  Chapter  3  the  user  specification  interface  and  mechanisms  for 
QoS  specification  acquisition  are  addressed.  In  Chapter  4  we  clasify  our  QoS  manage¬ 
ment  problem  and  discuss  the  design  principles  for  the  corresponding  algorithms.  In 
Chapter  5  and  Chapter  6  we  presents  our  algorithms  for  single  resource  multiple  QoS 
dimension  and  multiple  resource  multiple  QoS  dimension  problem  respectively,  with 
theoretical  measure  of  their  performances.  Experimental  performance  evaluation  is 
conducted  in  Chapter  7.  Finally,  we  draw  conclusions  and  discuss  future  work  in 
Chapter  8. 


Chapter  2 

Quality  Index  and  QoS  Modeling 


In  this  chapter,  we  are  going  to  formalize  our  QoS  management  problem.  First, 
however,  we  need  to  regularize  the  problem  using  a  concept  we  call  quality  index. 
This  is  a  mapping  from  qualities  to  indices  in  uniform  way.  Using  quality  index  as 
basis,  we  transform  the  QoS  management  problem  into  a  optimization  problem  which 
utltimately  enables  us  to  quantitatively  measure  QoS,  and  to  analytically  plan  and 
allocate  resources. 


2.1  Quality  Dimensions 

Consider  a  video-streaming  system  which  deals  with  real-time  audio  and  video  data 
streams  being  encrypted  and  transmitted  across  potentially  unreliable  networks.  In 
this  context,  we  consider  the  following  example  quality  dimensions: 

•  Cryptographic  Security  (encryption  key-length) 

—  O(off),  56,  64,  128 

•  Data  Delivery  Reliability,  which  could  be 

—  maximum  packet  loss:  measured  in  percentage 

—  expected  packet  loss:  measured  in  percentage 

—  packet  loss  occurrence:  measured  as  the  probability  that  one  or  more  pack¬ 
ets  are  lost  over  the  length  of  the  session. 
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•  Video  Related  Quality 

-  picture  format^:  SQCIF,  QCIF,  GIF,  4CIF,  16CIF 

-  color  depth(bits):  1,  3,  8,  16,  24,  ... 
black/white,  grey  scale  to  high  color 

-  video  timeliness  —  frame  rate(fps):  1,  2,  . . . ,  30 
low  rate  animation  to  high  motion  picture  video 

•  Audio  Related  Quality 

-  sampling  rate(kHz):  8,  16,  24,  44,  . . . 

AM,  FM,  CD  quality  to  higher  fidelity  audio 

-  sample  bit(bits):  8,  16,  ... 

-  audio  timeliness,  or  end-to-end  delay(ms) 

. . . ,  25,  50,  75,  100,  . . . 

For  the  sake  of  this  example  we  assume  that  cryptographic  key  lengths  are  in¬ 
dicative  of  the  level-of-security  provided.  This  is  not  generally  true.  For  example,  a 
56-bit  DES  encryption  is  a  vast  improvement  over  a  128-bit  RSA  encryption.  But  as 
we  shall  see  shortly,  all  we  require  is  the  ability  to  place  an  ordering  on  the  choices. 

Notice  that  all  quality  dimensions  have  a  discrete  set  of  options.  For  some,  picture 
format  for  instance,  this  is  natural;  for  others,  audio  timeliness  for  example,  we  require 
that  a  discrete  set  of  choices  be  selected.  It  is  not  explicit  from  the  example  above, 
but  we  also  require  that  the  set  of  choices  be  finite. 


2.2  Quality  Index 

As  the  example  above  shows,  quality  dimensions  can  differ  radically  from  each  other 
in  nature.  Certain  quality  dimensions,  such  as  frame  rate,  can  have  a  regular  quality 
specification,  while  others,  such  as  picture  format,  color  depth  and  end-to-end  delay, 
are  non-numeric,  non-uniform,  or  in  non-increasing  order.  For  example,  there  is  color 

^The  choices  listed  here  come  from  [16]  [51].  Other  standards,  such  as  MPEG  could  have  been 
used  instead. 
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depth  where  high  numbers  corresponds  to  high  quality.  Then  there  is  audio  timeliness, 
where  high  numbers  means  low  quality. 

In  order  to  present  a  coherent  formalization  of  the  QoS  management  problem,  we 
need  to  regularize  the  quality  dimensions.  To  this  end,  we  introduce  the  notion  of 
Quality  Index,  which  is  a  mapping  between  qualities  to  integers  (“indices”)  starting 
with  one  in  such  a  way  that  higher  indices  correspond  to  higher  quality. 

For  the  video  application  (assume  it  is  T*  in  the  system)  introduced  ealier,  we 
would  have  the  following  quality  indices. 

Picture  format:  Assume  it  uses  the  H263  [16]  standard  format 

Format:  SQCIF  QCIF  GIF  4CIF  16CIF 

Quality  Index:  1  2  3  4  5 

The  corresponding  Quality  Index  is  therefore  Qa  —  {1, 2, 3, 4, 5}. 

Color  depth:  Assume  that  Ti  has  1,  3,  8,  16,  and  24  bit  color  depths  available  for 
the  user  to  choose. 

Depth:  1  3  8  16  24 

Quality  Index:  1  2  3  4  5 

Therefore  Qi2  =  {1, 2, 3, 4, 5}. 

Frame  rate:  Ti  allows  frame  rates  ranging  from  1  fps  to  30  fps  in  steps  of  1  fps. 
These  will  map  directly  onto  Qis  =  {1,2,...,  30}. 

Rate  (fps):  1  2  ...  30 
Quality  Index:  1  2  ...  30 

Encryption  key  length:  For  T,  encryption  will  be  either  on  with  56-bit  encryp¬ 
tion  or  olP.  Therefore  we  have  Qi4  =  {1, 2}. 

Key  length:  (none)  56-bit 

Quality  Index:  1  2 

Audio  sampling  rate:  Assume  Tj  provides  audio  sampling  rates  from  AM-quality 
(8  kHz)  to  CD-quality  (44  kHz). 


^For  the  simplicity  of  illustration,  we  reduced  the  levels  of  encryption  to  2  from  the  4  in  previous 
example  in  2.1.  We  also  omited  the  quality  dimensions  related  with  data  delivery  reliability  here. 
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Sampling  rate  (kHz):  8  16  24  44 

Quality  Index:  12  3  4 

Thus  we  have  Qi^  —  {1, 2, 3, 4}. 

Audio  bit  count:  Assume  that  Ti  provides  only  two  sampling  sizes,  8  bits  and 
16  bits. 

Bit  count:  8  16 
Quality  Index:  1  2 

Therefore  Qi^  =  {1, 2}. 

End-to-end  delay:  Assume  that  end-to-end  delays  ranging  from  125  ms  to  25  ms 
in  steps  of  25  ms.  Since  high  numbers  for  end-to-end  delay  are  worse  than  low 
numbers,  high  numbers  are  mapped  to  low  indices  in  the  set  Qj?  =  (1, 2, . . . ,  5}. 

Delay  (ms):  125  100  ...  25 
Quality  Index:  1  2  ...  5 

i 

Quality  Index  Hence  Quality  Index  is  essentially  a  bijective  function  between  a 
task’s  dimensional  quality  space  and  natual  numbers 

fij  •  Qtj  {1, 2, . . . ,  IQy  1} 

that  provides  a  uniform  and  consistent  ordering  of  dimensional  quality  space.  That 
is,  if  qi  is  “better  than”  ga,  then  fij{qi)  >  fij{q2)-  Since  fij  is  bijective,  it  has  an 
inverse  =  {{y,x)  |  {x,y)  e  /},  i.e.  :  {1, 2, . . . ,  \Qi^\}  Q^. 

Prom  now  on,  we  will  mostly  use  Qij  and  qij  to  represent  their  corresponding  /y- 
indexed  quality  sets  and  quality  points,  except  in  occasional  cases.  This  should  not 
cause  any  confusion  as  the  context  clearly  determines  whether  the  original  quality 
specification  or  index  value  is  under  consideration. 

Note  that  this  abstraction  forms  the  basis  of  our  quantitative  and  analytic  ap¬ 
proach  for  QoS  management,  including  the  QoS  based  resource  allocation. 
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2.3  QoS  Tradeoff  and  Application  Utility 


By  QoS  tradeoff  or  quality  tradeoff  we  mean  an  assignment  of  value  to  each  possible 
quality  point.  This  valuation  is  central  to  our  model  and  it  allows  the  management 
system  to  take  the  task’s  and  the  user’s  preferences  into  account  when  allocating 
resources.  The  function  that  describes  a  task’s  valuation  is  known  as  the  application’s 
utility  function,  UiiQi^M  where  Qi  represents  the  set  of  all  possible  quality  points, 
and  IR  is  the  set  of  real  numbers. 

In  a  system  where  resources  are  in  high  demand  and  in  which  not  every  task  can 
be  allocated  the  resources  it  wants,  tasks  can  benefit  from  QoS  tradeoff.  In  order  to 
see  this,  consider  first  a  task  in  a  system  that  does  not  have  QoS  tradeoff.  If  a  resource 
used  by  this  task  gets  over-subscribed,  the  system  will  have  to  either  reject  the  task, 
or  lower  the  assigned  resource  and  thus  quality  and  utility  at  its  own  discretion. 

With  QoS  tradeoff,  however,  if  the  system  cannot  fulfill  the  resouce  demands  for 
a  particular  quality  mode,  it  can  use  the  QoS  tradeoff  information  to  make  smart 
decision  on  alternative  and  perhaps  equally  desired  mode.  If  the  resource  usages 
of  the  equally  desired  choices  cannot  be  satisfied,  the  system  can  lower  the  service 
quality  in  a  way  that  affects  the  user  minimally.  As  a  result,  the  task  might  be  able 
to  run  at  an  acceptable,  if  sub-optimal,  level  of  service.  Since  quality  is  at  least 
partially  subjective,  it  is  important  that  the  user  be  allowed  to  infiuence  the  QoS 
tradeoffs.  Therefore  it  is  to  the  user’s  significant  advantage  for  a  system  to  provide 
the  capability  and  interface  that  allows  the  user  to  make  implicit  or  explicit  quality 
tradeoffs.  We  will  consider  user  interfaces  implications  in  Chapter  3. 

With  QoS  tradeoff,  our  QoS  management  optimization  engine  will  work  most 
effectively  to  help  each  task  achieve  as  high  level  of  quality  as  possible,  subject  to 
resource  constraints  and  the  management  policy  deployed  in  the  system. 

The  benefits  of  QoS  tradeoff  become  even  larger  in  a  dynamic  environment,  where 
resources,  processing  power  and  the  link  speed,  on  or  between  the  end  and  inter¬ 
mediate  nodes  might  dynamically  change,  and  an  application’s  resource  allocation 
fluctuates  during  the  course  of  operation. 
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2.4  Resource  Tradeoff 

The  more  resource  an  application  is  given,  the  better  quality  it  can  provide.  With  this 
in  mind,  one  might  naively  think  that  the  relationship  between  resource  and  quality 
could  be  described  as  a  function. 

Unfortunately,  this  does  not  work  in  the  context  of  multiple  resources  and  quality 
dimensions.  This  is  because  an  application  can  choose  between  two  or  more  algo¬ 
rithms  that  achieve  the  same  quality  but  using  different  resources.  Consider  data 
transmission  where  two  different  compression  algorithms,  Ai  and  A2  are  available  to 
use.  Assume  that  Ai  has  a  relatively  low  compression  rate,  but  is  computationally 
cheap,  whereas  A2  has  a  high  compression  rate,  but  is  computationally  more  expen¬ 
sive.  To  the  user,  the  end  result  after  decoding  will  be  the  same  no  matter  what 
algorithm  is  in  use.  But  using  A2  results  in  more  CPU  processing  power  and  less 
network  bandwidth  compared  to  that  of  Ai. 

tai  =  {nr-', I'm) 

This  example  shows  that  one  quality  point  can  correspond  to  multiple  resource 
usage  points.  Thus  we  cannot  describe  the  situation  as  a  function  from  quality  space 
to  resource  space. 

Likewise,  given  a  resource  allocation,  an  application  can  use  this  to  improve  quality 
along  one  of  several  quality  dimensions,  which  yields  different  quality  results.  For 
example,  in  a  video  conferencing  session  with  limited  network  capacity,  the  bandwidth 
can  be  used  primarily  for  video  to  improve  the  picture  quality,  or  used  primarily  for 
audio  thereby  increasing  the  sound  quality. 

QA^  =  {qu  ’-,qd) 

m 

qA2^  (q'lr-jq'd) 
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This  example  shows  that  one  resource  point  can  correspond  to  multiple  quality 
points.  Therefore  we  cannot  expected  to  have  a  function  from  resource  space  to 
quality  space  that  describes  the  quality  in  terms  of  resource  allocation.  Instead,  only 
a  scatter  for  R  and  Q  can  be  drawn. 

Consequently,  only  a  relation,  but  not  a  function,  can  be  defined  between  Qi 
and  R.  We  elect  to  model  the  relationship  between  the  resource  and  quality  in  the 
most  general  fashion,  that  is  as  a  mathmatical  relation: 

r\=i<l 

A  resource  choice,  r  £  R,  and  a  quality  point,  q  G  Qi,  are  in  relation  if  task  Ti  can 
achieve  quality  q  using  resource  r,  but  not  less. 

Note  that  both  R  and  Qi  have  partial  orderings  which  |=j  must  respect,  i.e.,  more 
resource  must  not  lead  to  lower  quality.  That  is,  if  ri  |=i  qi,  r2~  \=i  92,  and  ri  >  r2, 
then  we  must  have  qx  q2- 

This  requirement  ensures  that  utility  is  non-decreasing  with  respect  to  resources. 
In  other  words,  more  resources  should  not  lead  to  reduced  quality  (and  thus  utility), 
which  is  reasonable  and  natural. 


2.5  Problem  Formulation 

In  this  section,  we  are  going  to  formally  describe  the  QoS  management  problem 
including  the  QoS  based  resouce  allocation.  We  will  formalize  it  as  a  optimization 
problem. 

Consider  a  system  with  multiple  independent  applications  and  multiple  resources. 
Each  application,  with  its  own  quality-of-service  requirements,  contends  with  others 
for  finite  system  resources.  Let  the  following  be  given 

Ti,  T2,  . . . ,  Tn  —  tasks  (or  applications) 

Ri,  R2,  Rm  —  shared  system  resources 
Qii-,  Qi2i  •  •  • ,  Qidi  —  QoS  dimensions  for  task  Ti 
Each  Ri  is  a  set  of  non-negative  values  representing  the  possible  allocation  choices  of 
the  ith  shared  resource.  The  set  of  possible  resource  vectors,  denoted  as  R,  is  given 
hy  R  =  Ri  X  •••  X  Rm-  The  available  amount  of  each  shared  resource  is  finite,  so  we 
also  have  , . . . ,  r™^^) . 
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Similarly,  each  Qij  is  a  finite  set  of  quality  choices  for  the  zth  task’s  jth  QoS 
dimension,  and  we  define  the  set  of  possible  quality  vectors  for  task  T,  by  Qi  = 
Qii  X  •  •  •  X  Qid,. 

2.5.1  Task  Profile 

Associated  with  each  Tj  is  a  task  profile,  which  is  a  characterization  of  Ti  on  quality 
and  resource  requirement.  It  consists  of  an  application  profile  and  a  user  profile.  An 
application  profile  comes  from  an  application  designer,  while  a  user  profile  provides 
user-specific  quality  requirements  associated  with  each  session. 

A  user  can  either  instantiate  the  quality  attributes  of  the  default  application 
profile,  by  selecting  one  of  many  templates  supplied  with  the  application,  or  the  user 
can  supply  their  own  reward  functions  with  respect  to  different  levels  of  qualities. 

2. 5. 1.1  Application  Profile 

An  Application  Profile  consists  of  a  QoS  Profile  and  a  Resource  Profile. 

QoS  Profile  A  QoS  Profile  consists  of 

•  Quality  Indices  —  Qij,  1  <  j  <  di. 

•  Quality  Space  —  Qi  =  Qn  x  •  ^  •  x  Qio,. 

•  Application  Utility  —  a  QoS  or  rate  of  service  measure 

Ui .  Qi  ^  m. 

which  for  each  quality  point  specifies  a  utility  in  the  form  of  a  non-negative 
number. 

Resource  Profile  A  Resource  Profile  for  Ti  is  a  description  of  the  application’s 
resource  usage  at  different  levels  of  quality.  Due  to  resource  tradeoff  and  quality 
tradeoff  as  described  earlier,  we  cannot  expect  this  to  be  a  function  (the  scatter  plot 
in  Figure  2.1,  which  depicts  a  possible  relation  between  resource  and  quality,  might 
help  us  visualize  this).  Instead  we  use  the  relation  r  \=iq. 
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Figure  2.1:  Scatter  of  Resource  and  Quality 

2. 5. 1.2  User  Profile 

A  User  Profile  is  an  instantiation  of  the  application  profile  with  perhaps  some  addi¬ 
tional  QoS  requirement. 

•  The  QoS  profile  part  of  application  profile  provides  a  template  which  a  user 
can  instantiate  to  create  a  user  profile.  A  user  can  also  supply  his/her  own 
QoS  profile  which  supersedes  those  provided  by  the  application. 

•  QoS  Constraint:  is  the  minimum  QoS  requirement  specification 

^min  _  /^min  _min 

Qi  \Qil  ^Qi2  ?  •  •  •  ^^idi  /• 

The  semantics  of  9™’"  is  that  if  the  minimum  requirements  cannot  be  satisfied, 
then  the  application  cannot  run  or  the  user  prefers  not  to  run  T*  at  all. 

•  Saturation  point:  A  user  may  explicitly  specify  a  cap,  or  saturation  point, 
qf'^,  on  its  quality  requirement  to  indicate  that  further  improvements  beyond 
it  are  not  likely  to  be  perceived  or  appreciated.  Similar  to  the  discussion  of  g*"™ 
above,  the  maximum  quality  constraint  could  be  handled  by  setting 

Ui{q)  :=  all  q  > 

To  simplify  algorithm  descriptions,  we  will  not  explicitly  use  this  aspect  in  the 
algorithms  presented  later  in  this  thesis. 
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In  general,  Task  Profile  will  be  used  to  represent  the  effect  of  using  an  application 
profile  that  has  been  instantiated  by  the  user  profile.  Occasionally  we  will  not  distin¬ 
guish  the  two  sources  and  use  task  profile  for  application  profile  and  user  profile  as 
well. 

For  the  overall  system,  with  multiple  applications  possibly  requiring  multiple  re¬ 
sources,  system  utility  can  be  introduced  and  defined. 


2.5.2  System  Utility 

Each  task  has  a  utility  function  that  measures  the  value  it  puts  on  a  quality  as¬ 
signment.  We  will  use  these  utility  functions  to  define  an  overall  System  Utility, 
u  :  Qi  X  •  ■  ■  X  Qn  ^  JR.  Many  different  definitions  are  possible,  depending  on  the 
system  or  policy  in  question.  Examples  include: 

•  u  =  Uw,  a  (weighted)  sum  of  application  utilities 

n 

Uu,{qi,...,qn}  =  Wiufiqi) 

i—1 

for  differential  services,  where  Ui  is  non-decreasing,  and  0  <  <  1  could  be 

the  priority  of  Tj,  or 


•  u  =  u* ,  where 


for  “fair”  sharing. 


u*{q\,...,qn)  =  min  ufiqi) 


Note  that  the  algorithms  or  schemes  presented  in  this  thesis  are  for  the  weighted 
sum  where  the  weights  are  set  to  1  for  simplification  to  present  the  algorithms. 

As  the  reader  can  see,  the  QoS  management  model  is  very  flexible  and  powerful.  It 
can  be  adapted  to  fit  a  variety  of  situations.  In  this  thesis,  however,  the  weighted-sum 
definition  is  used  for  system  utility. 


2.5.3  Optimization  Formulation 

Given  a  set  of  task  profile,  our  goal  is  to  assign  qualities  {qi)  and  allocate  resources 
(rj)  to  tasks  or  applications,  such  that  the  system  utility  u  is  maximized.  Therefore 
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we  have  the  following  Problem  Function  formulation 
maximize  u{qi,...,qn) 

subject  to  qi  >  qf'^  or  =  0  ,  i  =  1, . . . ,  n,  (QoS  Constraints) 

p.i) 

(Resource  Constraints) 

i—1 

fi  Qi  1  2  =  1,  .  .  .  ,  n. 

Due  to  the  presence  of  a  general  relation  (r  |=i  q)  in  the  constraints,  this  optimiza¬ 
tion  problem  is  different  from  what  is  found  in  the  general  optimization  literature. 
But  we  shall  see  in  Section  4.2  that  the  problem  can  be  transformed  into  a  general 
combinatorial  optimization  problem. 

If  maximizing  the  profit  margin,  rather  than  the  users’  appreciation  of  the  quality, 
is  the  objective  goal  of  the  system,  the  objective  function  u{qi, . . . ,  in  Equation  2.1 
would  be  u  {{qi,ri), {qn,  Vn))  which  is  defined  as 

n 

u((gi,ri),...,(5n,'rn))  =  “  cost{ri))  (2.2) 

i=l 

The  algorithms  to  be  described  in  the  Chapters  5  and  6  for  Formulation  2.1  can 
be  used  straightforwardly  with  only  trivial  changes  for  the  problem  with  modified 
objective  function  in  Equation  2.2.  See  Section  2.6.3  for  further  discussion  on  the 
profit-based  QoS  management  problem. 

2.6  Expressive  Power  of  Model 

In  order  to  show  that  the  model  described  in  last  section  is  semantically  rich,  we  will 
now  show  how  some  other  models  can  be  embedded  into  it. 

2.6.1  Basic  Priority  Scheme 

With  the  basic  priority  scheme,  a  task  with  high  priority  is  selected  or  admitted  to 
run  over  lower  priority  tasks,  unless  it  is  not  possible  to  nrn  the  high  priority  task  at 
all. 
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Let  p(Ti)  be  the  priority  of  Ti.  Let  us  further  assume  that  tasks  with  high  priorities 
are  assigned  low  numbers  and  low  priorities  assigned  high  numbers. 

To  ensure  that  the  system  exhibits  the  basic  priority  behavior,  we  need  to  control 
the  task  admission  in  a  way  that  a  task,  say  Tj,  will  not  be  accepted  to  run  unless 
all  tasks  with  higher  priority  have  been  accepted  or  resources  required  by  Tj  exceed 
the  available  resource  after  tasks  with  higher  priority  than  Tj  are  admitted.  We  will 
show  that  this  basic  priority  policy  can  be  realized  in  Formulation  2.1  through  weight 
assignment  and  by  giving  a  task  utility  1  if  it  runs  (and  utility  0  if  it  does  not  run). 

Let 


p  :  {Ti,...,Tn}  {1,  ...,n} 


be  a  bijective  function  that  describes  the  tasks’  priorities  with  1  as  the  highest  and  n  as 
the  lowest  priority.  We  shall  see  later,  that  this  function  actually  need  not  be  bijective, 
and  a  group  of  tasks  are  allowed  to  have  the  same  priority.  We  require  bijectivity 
here  for  notational  simplicity  so  we  can  make  reference  to  p’s  inverse  function,  p~^. 

We  want  to  show,  that  if  Tj  is  admitted  to  run  (i.e.,  it  is  allocated  non-zero 
resource)  then  all  Tj  with  higher  priority,  p{Tj)  <  p{Ti),  are  also  admitted  to  run.  We 
can  ensure  this  by  simply  assigning  task  Ti  a  weight  of  Wj  :=  where  p(Tj)  is 

the  priority  of  T,. 

We  will  demonstrate  that  such  a  assignment  guarantees  that  a  task  with  a  higher 
priority  will  contribute  more  towards  the  system  utility  than  the  utilities  combined 
by  all  tasks  with  lower  priorities,  therefore  would  be  admitted  in  the  system  unless 
its  resource  requirement  exceeds  the  reminding  resources  after  higher  priority  tasks 
are  alloted.  In  other  words,  we  need  to  show  that: 


n 

WiUiiq)  > 

3=P(Ti)+l 


Expressive  Power  of  Model  19 


Substituting  the  assignment  in  for  Wi  and  each  Wj,  we  have 


2  >  S  2  %p-i(j)(9) 

j=p(Ti)+l 


1  >  u  ( r  1 1 

j=p(Ti)+l 


l\P(Ti) 

2) 


> 


'  °°  /1\^ 
j=^p(Ti)+l 


iT’  >-  iT'W 


00  j 

>  E  5 

,=o 


The  right  hand  side  of  the  last  inequality  is  an  infinite  decreasing  geometric  series, 
which  converges  to  2.  Thus  Problem  Formulation  2.1  with  the  weights  set  above 
indeed  realizes  the  basic  priority  scheme. 

If  multiple  tasks  have  the  the  same  priority,  the  weights  can  be  adjusted  in  the 
following  way.  First,  give  all  tasks  a  distinct  priority,  and  let  the  tasks  to  have  the 
same  priority  be  adjacent,  but  their  relative  order  can  be  arbitrary.  Then  designate 
weights  using  p(-).  Subsequently,  for  groups  of  tasks  that  have  the  same  priority,  use 
the  lowests  weight  of  the  group  for  all  the  tasks  in  this  group.  Since  doing  this  only 
lowers  the  weight  of  each  task  to  the  lowest  of  this  group,  the  utility  condition  still 
holds. 


2.6.2  Enhanced  Prioritized  Allocation 

Assume  that  tasks  in  the  systems  are  in  adaptive  nature  as  well  as  prioritized.  One 
might  wonder  whether  we  can  have  a  system  that  lets  admitted  task  run  with  various 
levels  of  quality  (therefore  potentially  different  utility)  while  still  enforcing  that  tasks 
are  admitted  based  on  their  priority.  We  will  refer  such  policy  adaptive  prioritized 
allocation,  and  we  will  show  that  Problem  Formulation  2.1  can  realize  this  adaptive 
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prioritized  allocation  scheme.  To  see  this,  let  again 

P  ■  {Ti, . . . ,  Tn}  — >  {1, . . . ,  n} 

be  a  bijective  function  that  describes  the  tasks’  priorities  with  1  as  the  highest  and 
n  as  the  lowest  priority.  Again  this  function  need  not  be  bijective,  and  tasks  are 
allowed  to  have  the  same  priority.  As  in  Section  2.6.1  we  require  bijectivity  here  for 
notational  simplicity. 

Assume  that 

Ui{q)  e  1]  for  all  i  and  q^Qi 

where  6i  6  (0, 1]  describes  the  utility  range  of  Ti. 

We  want  to  show  that  if  Ti  is  admitted  to  run,  no  matter  upon  which  level  of  quality 
it  will  operate,  then  all  Tj  with  higher  priority,  p{Tj)  <  p{Ti),  are  also  admitted  to 
run  with  one  of  the  quality  modes  specified  in  their  corresponding  quality  spaces, 
unless  resources  required  by  Tj  exceeds  the  available  amount.  We  can  ensure  this  by 
assigning  proper  weights,  Wi,  in  the  following  way. 

Let  5  =  min  5i,  Wi  =  (5/2)^^^*)  and  let  p~^  be  the  inverse  function  of  p.  We  will 
now  prove  that  such  weight  assignments  guarantees  that  a  task  with  a  higher  priority 
contributes  more  towards  the  system  utility  than  the  utilities  combined  by  all  tasks 
with  lower  priorities: 
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t 

It 

$ 

tt 

$ 


n  • 

j^p{Ti)+l 

n 

(V2)''<’''>«i(«)  >  E  (■5/2)4p-.0)(?) 

J=P(7<)+1 

{5/2y^'^^'^5  >  {s/2yi 

j=p{Ti)+l 

oo 

{s/2y^^*^s  >  Y1  (V2y 

j=P{Ti)+l 

00 

>  (5/2f  f;(5/2y 

j=o 

(V2)'<"’<>i  >  ('5/2)»m*+'j^ 


2  > 


1 

1-5/2 


1  >  5 


The  latter  inequality  is  true  by  assumption,  so  the  former  is  always  true.  Thus  the 
model  in  2.1  with  the  weights  set  as  claimed  realizes  the  QoS  adaptive,  or  enhanced, 
prioritized  allocation. 


2.6.3  Profit  as  Utility 

As  mentioned  above,  the  system  with  objective  funtion  defined  as  in  Equation  2.2  can 
be  solved  directly  using  the  algorithms  to  be  described  later  in  this  thesis.  Neverthe¬ 
less  we  will  now  show  how  it  can  also  be  embedded  into  the  model  in  2.1  by  reducing 
the  profit-based  problem  to  an  instance  of  the  problem  described  in  2.1.  In  order  to 
differentiate  the  symbols  of  one  problem  from  the  symbols  of  the  other,  the  symbols 
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of  the  profit-based  problem  will  be  underlined. 

R 

{{quu)  e  Q.X  Eln 

(qT^O) 

MiiS'^iqi))  -  cost{£'^ (qi))  +  C 

where  is  a  function  that  extracts  the  r  component  from  a  g-r-pair  and  extracts 
the  q  component.  The  (partial)  ordering  of  elements  in  Qi  is  inherited  from  Q^. 
The  constant  C  is  defined  as  max,.  cost{r) .  It  is  used  to  ensures  that  utilities  remain 
non-negative,  and  it  does  not  influence  the  optimization  result  in  any  other  way. 

It  can  now  be  seen  that  this  is  a  problem  instance  of  Equation  2.1  and  that  it 
solves  the  profit-based  management  problem. 

2.6.4  Connected  or  Conditional  QoS  Requirements 

With  the  introduction  of  quality  indices  and  quality  dimensions,  connected  or  condi¬ 
tional  QoS  requirements  can  also  be  easily  specified  in  the  QoS  management  system. 

Assume  that  the  user  wants  to  add  conditions  on  the  quality  apportioning  across 
quality  dimensions,  e.g.,  the  user  might  require  that  the  quality  on  one  dimension 
is  contingent  on  the  offered  quality  of  another  dimension.  For  example,  for  a  video 
streaming  session,  a  user  might  require  that  the  video  frame  rate  follow  frame  reso¬ 
lution  in  either  the  same  or  opposite  direction,  such  as 

{(5fps,QCIF),  (10fps,CIF), . . . ,  (15fps,  16CIF)} 

where  the  rates  follow  each  other,  or 

{(5fps,  16CIF),  (10fps,4CIF), . . . ,  (15fps,  QCIF)} 

where  the  rates  go  against  each  other.  This  can  be  viewed  as  the  user  explicitly 
disallowing  certain  quality  points,  or  alternatively  as  restricting  the  set  of  valid  QoS 
points.  This  conditional  QoS  requirements  can  be  accommodated  in  one  of  the  fol¬ 
lowing  ways: 


R  = 
Qi  = 

min  _ 

% 

qi 

Ui{qi)  = 
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Pre-digitize  Quality  Space  in  User  Profile  When  the  size  of  the  qualified  (or 
disqualified)  quality  space  is  small,  we  can  let  the  user  specify  the  qualifying  (or 
disqualifying  if  the  number  of  disallowed  points  is  smaller)  points. 

Augment  QoS  Constraints  Alternatively,  we  can  simply  let  the  user  describe  the 
connected  QoS  requirements  through  predicates  as  augmented  QoS  constraints. 

Augment  Resource  Profile  Furthermore,  the  system  can  faciliate  such  condi¬ 
tional  QoS  requirements  through  restricting  r  \=i  q.  Let  C  be  the  qualifying 
points.  We  can  embed  this  into  the  model  described  in  2.1  by  simply  making  sure 
that  r  |=j  g  is  never  true  for  any  such  q,  i.e.,  using 

r\=^q  =  q^Ql/\r\=iq 


as  our  resource  profile. 

2.6.5  Functional  Qi-R  Relationship 

Many  authors,  for  example  [53,  22],  assume  a  functional  relationship  between  resource 
and  quality,  i.e.,  either  qi  =  /^(rj)  or  Vi  —  fr{qi)  for  suitable  fg  or  R.  Such  functions 
are  special  cases  of  our  general  relation,  r\=iq. 


2.7  Chapter  Summary 

This  chapter  formalized  our  QoS  management  problem  and  introduced  the  basic  en¬ 
tities  of  our  model.  It  first  introduced  the  notion  of  quality  dimensions  across  which 
optimization  will  need  to  be  performed.  The  concept  of  quality  index  allows  a  map¬ 
ping  from  non-uniform  QoS  dimensions  to  integers.  The  notion  of  application  utility 
is  used  to  quantify  the  relative  merits  of  various  QoS  points.  QoS  tradeoffs  can  there¬ 
fore  be  made  based  on  application  utilities.  The  same  QoS  operating  point  can  be 
satisfied  by  making  tradeoffs  among  resources.  For  example,  CPU  time  might  be 
traded  for  network  bandwidth  by  compressing  or  not  compressing  a  video  stream. 

Profiles  are  used  to  characterize  applications  and  their  requirements.  A  task  profile 
characterizes  the  relationship  between  QoS  and  resource  requirements,  and  consists 
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of  an  application  profile  and  a  user  profile.  An  application  profile  consists  of  a  QoS 
profile  and  a  resource  profile.  The  QoS  profile  specifies  the  utility  of  all  possible 
QoS  points,  or  modes,  while  the  resource  profile  specifies  the  relation  between  the 
QoS  points  and  the  resources  necessary  to  achieve  them.  The  application  profile  is 
typically  created  by  the  application  designer.  The  user  profile  is  a  possibly  customized 
instantiation  of  an  application  profile  by  the  end-user. 

The  goal  of  our  optimization  is  to  assign  qualities  and  the  corresponding  allocation 
of  resources  to  applications  such  that  the  total  system  utility  is  maximized.  This 
optimization  model  is  semantically  rich  and  can  also  be  used  to  model  traditional 
schemes  such  as  prioritized  allocation  and  “fair”  sharing  schemes.  The  model  also 
supports  conditional  QoS  requirements,  where  the  quality  along  one  dimension  is 
contingent  on  the  offered  quality  along  another  dimension. 

In  conclusion,  our  QoS  management  model  can  be  very  flexible  and  expressive. 
Here  we  only  describe  several  examples  of  realization  schemes.  We  expect  that  this 
formulation  is  capable  of  modelling  and  supporting  the  ever  demanding  and  sophis¬ 
ticated  QoS  requirements. 


Chapter  3 

Specification  Methodology  for  QoS 
Provision 


At  the  crux  of  our  translucent  QoS  management  optimization  system  lies  the  QoS 
specification.  It  is  important  that  we  provide  a  powerful  and  semantically  rich  QoS 
specification  for  the  system  to  use  for  service  optimization.  Equally  important  we 
need  to  provide  a  mer  friendly  interface  that  facilitates  specification  acquisition. 

The  reason  for  the  emphasis  on  QoS  specification  and  interface  design  might  not 
be  obvious,  but  the  reader  should  see  the  point  shortly  when  we  take  a  closer  look  at 
the  quality  space  of  a  typical  multimedia  systems. 

QoS  specifications  represent  the  combined  wishes  of  the  user  and  the  application 
writer.  But  while  the  application  writer  can  be  assumed  to  be  willing  to  spend 
substantial  effort  in  order  to  produce  a  suitable  QoS  specification  for  optimization, 
the  same  is  not  true  for  the  user  who,  after  all,  is  interested  in  using  the  application, 
not  in  pleasing  the  optimization  system.  On  one  hand,  this  puts  a  severe  constraint 
on  the  level  of  complexity  that  the  application  can  present  to  the  user  for  purposes 
of  QoS  control.  On  the  other  hand,  the  user  must  be  presented  with  enough  options 
that  his  or  her  desires  can  be  adequately  expressed.  Therefore,  the  user  interface 
must  strike  a  careful  balance. 

In  our  previous  work  [29],  we  presented  RT-Phone  (Figure  3.1),  an  IP  video  con¬ 
ferencing  system  with  some  preliminary  QoS  control.  This  system  had  two  modes  of 
user  control  over  quality  —  basic  and  advanced. 

In  the  basic  mode,  we  had  a  simple  interface  in  which  overall  quality  of  service  was 
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Figure  3.1:  A  Screendump  of  RT-Phone 


selected  on  a  scale  from  one  to  ten.  Each  point  of  the  increasing  scale  corresponded 
to  an  application- defined  quality  point.  Selecting  a  quality  point  for  the  RT-Phone 
model  is  equivalent  to  setting  both  and  to  the  same  value  in  the  model  of 
this  thesis,  that  is  to  say  the  RT-Phone  model  has  no  utility  concept.  It  should  be 
clear  that  just  selecting  on  a  scale  from  one  to  ten  is  a  fairly  coarse  way  of  specifying 
quality,  as  we  can  think  about  it  as  a  “QoS  digitization”  by  the  application  designer 
(rather  than  the  end  user)  where  many  of  the  quality  choices  will  be  ruled  out. 

The  RT-Phone  system  therefore  also  had  an  advanced  mode  that  allowed  users 
control  over  individual  quality  dimensions  (see  Figure  3.2).  Since  the  RT-Phone 
QoS  model  did  not  have  the  quality  index  and  utility  concepts,  the  power  of  QoS 
control  is  of  a  much  lesser  degree  than  suggested  in  the  example  of  Section  2.1.  We 
believe  that  the  principles  of  facilitating  the  dimensional  quality  control  in  advanced 
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mode  are  sound,  so  we  have  adapted  them  into  the  QoS  specification  model  defined 
in  [25,  30,  27]  and  this  thesis. 


Figure  3.2:  RT-Phone  QoS  Control 


3.1  Quality  Space 

The  application  utility  is  a  function  defined  on  the  set  of  quality  points,  Qi.  Therefore, 
producing  a  QoS  specification  consists  of  determining  a  value  for  each  element  in  Qi, 
either  directly  or  through  some  indirect  means. 

To  illustrate  this,  let  us  revisit  some  of  the  quality  dimensions  for  the  video  con¬ 
ferencing  system  shown,  in  section  2.1 
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Quality 

Choices 

Choice  Count 

Cryptographic  security 

0,  56 

2 

Picture  format 

SQCIF,  . . . ,  16CIF 

5 

Color  depth(bits) 

1,  3,  8,  16,  24 

5 

Frame  rate(fps) 

1,  2,  . . . ,  30 

30 

Sampling  rate(kHz) 

8,  16,  24,  44 

4 

Sample  size 

8,  16 

2 

Audio  end-to-end  delay(ms) 

25,  50,  75,  100 

4 

The  original  specification  had  ellipses,  ,  representing  more  choices  than  shown 
above.  We  will  ignore  those  here. 

The  size  of  the  QoS  specification,  that  is  the  total  number  of  different  quality 
points,  in  this  example  is 

di 

\Qi\  =  n  l^bl  =  2x5x5x  30  x4x2x4  =  48000. 

j=i 

With  this  many  quality  points,  it  is  clearly  infeasible  to  have  the  user  specify  the 
utility  on  a  point-by-point  basis;  there  are  simply  too  many  choices.  Therefore  a 
pragmatic  scheme  is  needed  to  address  the  issue. 

3.2  Dimensional  Utilities 

Obvious  way  of  trying  to  solve  the  specification  problem  is  to  have  the  user  specify 
the  utility  of  selected  quality  points  and  then  interpolate.  Unfortunately,  this  does 
not  work  well  in  a  multidimensional  quality  space,  where  the  quality  points  are  not 
completely  ordered.  For  example,  if  we  have  two  dimensions  each  with  two  points, 
there  will  be  four  quality  points: 

gi  =  {(1,1),  (1,2),  (2,1),  (2, 2)}. 

The  points  (1, 2)  and  (2, 1)  are  unordered.  The  lack  of  order  increases  with  the  number 
of  dimensions  and  turns  interpolation  into  extrapolation. 
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Gaining  insight  from  decision  science  as  well  as  our  previous  experience,  we  there¬ 
fore  provide  the  user  with  the  capability  to  specify  dimensional  quality  utilities.  The 
application  utility  can  then  be  defined  in  term  of  dimensional  utilities.  In  particularly, 
we  embed  the  dimensional  QoS  control  capability  scheme  into  our  utility  based  QoS 
management  model  by  allowing  task  Tj  to  specify  functions  Uij  :  Qij  IR,  one  for 
each  quality  dimension  j  G  {1, . . . ,  dj}.  We  call  these  “dimentional  utility  functions” 
and  combine  them  to  form  the  task’s  utility  function  as  we  shall  see  in  Section  3.3. 

The  quality  points  in  the  multidimensional  case  do  not  have  a  complete  ordering, 
but  the  individual  dimensions  do.  Moreover,  some  common  properties  associated 
with  dimensional  quality  utility  are  observed  including:  non-decreasing,  often  quasi- 
continuous  and  piecewise  concave.  Figure  3.3  depicts  some  typical  utility  function 
shapes.  Therefore,  the  applica;tion  writer  can  easily  define  and  supply  the  user  various 
such  function  classes  that  can  be  used  as  templates  for  the  user  to  instantiate  for  the 
dimensional  utility  function. 


Figure  3.3:  Typical  Dimensional  Utility  Functions 


Note  that  the  algorithms  presented  in  Chapters  5  and  6  rely  only  on  the  (quite 
natural)  property  of  non-decreasing  utility.  The  others  are  only  used  for  user  interface 
purposes  —  the  continuous-looking  graphical  presentation  of  a  function  template  only 
serves  the  purpose  of  easing  the  user  defining  his  QoS  utility  function. 

These  utility  fimction  classes  will  be  put  into  the  general  dimensional  utility  func¬ 
tion  template  pool.  Upon  sighting  a  matching  template,  the  user  can  customize  it 
with  actual  parameter  instantiation. 
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3.3  Construction  of  Application  Utility 

In  the  same  way  that  application  utilities  were  combined  into  an  overall  system  utility 
—  see  Section  2.5.2  —  we  can  now  combine  the  dimentional  utility  functions  into 
application  utility  functions.  One  reasonable  way  of  doing  this  is  to  use  a  weighted 
sum 

di 

uMi)  =  J2'^ijUij{Qij) 

and  for  the  remainder  of  this  thesis,  we  shall  do  just  that.  The  weights  allow  us  to 
emphasize  certain  quality  dimensions  at  the  expense  of  others. 

This  creates  an  interesting  issue  regarding  how  weights  should  be  assigned.  Cur¬ 
rently,  the  Analytic  Hierarchy  Process  (AHP)  [49]  is  used  to  cope  with  the  problem. 

By  using  dimensional  utility  functions,  we  have  reduced  the  number  of  utility 
values  that  need  to  be  determined  from  48000  above  to 

^  .  \Qij  \  =  2  -|-  5  -|-  5  -|-  30  T  4  -|-  2  -|-  4  =  52 

if  we  ignore  the  weights.  This  may  or  may  not  still  be  too  much  to  demand  from  the 
user,  but  we  shall  see  shortly  that  there  are  ways  of  bringing  it  down  even  further. 
Still,  a  reduction  of  three  orders  of  magnitude  is  a  good  start. 


3.4  Example  Dimensional  and  Application  Utility 


Again,  an  example  task  profile  will  be  presented  to  illustrate  the  possible  structure 
of  dimensional  utility  functions  and  application  utility  functions. 

Recall  that  application  utility  Ui  for  T*  is  defined  as  a  weighted  sum  of  the  dimen¬ 
sional  quality  utilities. 


di 

J=1 


where  Uij  are  the  dimensional  utility  functions.  Example  definitions  could  be: 


I 
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Function  Comments 


UiiiQn)  =  20qa 
Ui2iqi2)  =  100gi2/3 

uM  =  100(1  - 


uuiqu)  =  20(gi4  -  1) 
Ui^iqis)  =  100(1  - 


UieiQie)  =  50gi6 
Uiriqn)  =  20qi7 


Picture  format:  linear. 

Color  depth:  linear. 

Frame  rate:  exponential  decay,  assume  Tj  achieves  50% 
at  qi5  =  5  and  95%  at  q^  =  20.  Therefore  a  = 
-0.1535,5  =  0.0744. 

Encryption:  linear. 

Audio  sampling  rate:  exponential  decay,  Tj  acliieves  95% 
at  gi5  =  2  or  16  kHz. 

Audio  sampling  bits:  linear. 

End-to-end  delay:  linear,  achieves  100%  at  the  best  qual¬ 
ity  point,  qij  =  5  or  25  ms  delay. 


Figure  3.4  depicts  the  utility  curve  described  above  for  frame  rate. 


Suppose  Ti  is  a  remote  surveillance  system,  where  video  is  much  more  important  to 
the  user  than  audio.  Assume  that  SQCIF,  gray-scale,  low  frame  rate  is  fine  for  video. 
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and  there  is  no  need  for  encryption.  Therefore,  in  the  example  system  of  Section  2.2, 
we  could  have  the  following  minimum  quality  specification 

C"  =  (1,1, 2, 1,1, 1,2) 

which  corresponds  to  the  following  minimum  quality 

(SQCIF,  1  bpp,  2  fps,  no  encryption,  8  kHz,  8  bps,  75  ms) . 

Since  video  is  more  important  to  the  user  than  audio,  an  example  application 
utility  function  for  T*  could  be: 

■■•At)  =  +  •  •  •  +  ^^4(9^4))  +  +  •  •  •  + 

video  audio 

where  video  quality  is  weighted  five  times  more  than  that  of  audio. 


3.5  Other  Interface  Issues 

If  a  user  were  to  choose  quality  on  a  scale  of  1  to  10  with  some  pre-determined  quality 
choices  preset  by  the  system,  the  interface  would  be  very  simple,  but  such  built-in 
“QoS  digitization”  can  severely  limits  the  degree  of  customization. 

Satisfaction  Knee  Points  A  more  flexible,  but  also  more  sophisticated,  scheme 
would  be  to  have  a  set  of  parameterized  utility  curves  available  for  each  quality 
dimension,  and  to  have  the  user  pick  the  curves  and  instantiate  appropriate  param¬ 
eters/coefficients.  In  our  system,  the  instantiation  is  carried  out  by  letting  the  user 
graphically  specify  Satisfaction  Knee  Point  parameters.  For  the  exponential-decay 
used  in  the  previous  example  =  1  -  ^ggj.  could  specify  the  50% 

and  95%  levels.  This  is  enough  to  uniquely  determine  a  and  b.  For  example,  a  user 
could  specify  (5  fps,  0.50)  and  (20  fps,  0.95) ,  and  the  corresponding  utility  curve  would 
then  be  the  one  shown  in  Figure  3.4,  with  a  =  —0.1535  and  b  =  0.0744. 

Satisfaction  Knee  point  choice  can  be  realized  through  a  drag-able  marker  graphic 
interface.  Upon  choosing  a  utility  function  graph  outline,  a  user  can  drag  markers, 
representing  satisfaction  knee  points,  to  the  desired  positions.  The  corresponding 
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dimensional  utility  function  can  therefore  be  determined  and  fed  into  system  auto¬ 
matically. 

By  using  Satisfaction  Knee  points,  we  can  further  reduced  the  number  of  utility 
values  that  need  to  be  determined  from  52  above  to  approximately  two  for  each 
dimension  in  most  cases,  which  amounts  to  a  total  of  12  for  the  example  above. 

It  would  be  ideal  to  have  an  interface  that  can  assist  the  user  digitize  the  quality 
to  a  certain  range  of  scale,  and  acquire  the  corresponding  utility  accordingly.  Note 
that  such  mapping  process  is  different  from  the  built-in  QoS  digitization,  where  the 
quality  choices  are  pre-determined  by  application  designer. 

One  way  could  be  to  move  the  dimensional  utility  function  method  to  the  user 
interface  part  to  synthesize  or  digitize  quality-utility  data,  as  it  could  significantly 
reduce  the  quality  space  searched  by  the  QoS  management  optimizer.  This  especially 
crucial  if  the  management  system  is  to  be  deployed  on  a  gate  or  route  of  a  mediume 
or  larger  area  network. 

User  QoS  Constraint  Recall  the  definition  of  User  Profile  in  Section  2.5  we  allow  a 
user  to  specify  its  quality  constraints  explicitly  through  g™™.  Alternatively  we  could 
let  the  user  specify  the  constraints  implicitly  through  utility  functions  by  setting 
Ui{q)  =  0  for  all  q  <  gf*".  We  have  yet  to  complete  a  user-interface  study  to  decide 
whether  this  approach  will  compromise  the  simplicity  of  the  user-interface.  For  now, 
we  will  use  this  QoS  Constraint  approach.  In  this  thesis,  we  will  use  this  explicit  QoS 
Constraint  approach. 


3.6  Chapter  Summary 

This  chapter  presented  our  QoS  specification  methodology  with  emphasis  on  the  ap¬ 
plication  user.  The  application  utility  is  a  function  defined  on  the  set  of  quality  points, 
but  the  number  of  quality  points  to  be  considered  can  sometimes  become  unwieldy. 
Dimensional  utility  functions  represent  a  pragmatic  way  of  specifying  utility  values 
for  a  large  number  of  quality  points.  Affine,  concave  and  s-curves  are  three  typical 
dimensional  utility  functions.  The  dimensional  utility  functions  also  enable  the  ex¬ 
pression  of  conditional  QoS  requirements,  and  can  be  individually  modified  by  the 
end-user.  Our  dimensional  utilities  are  guided  by  the  results  from  decision  science 
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which  allow  relative  weights  to  be  assigned  to  various  dimensions. 


Chapter  4 

Problem  Complexity  and 
Algorithm  Design 


4.1  Problem  Taxonomy 

We  assume  that  multiple  applications  similar  to  the  one  described  in  Chapter  2  can 
co-exist  in  a  system.  We  classify  (Figure  4.1)  our  QoS  management  problem  based 
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Figure  4.1:  Problem  Classification. 

on  whether  the  system  deals  just  with  a  single  resource  or  with  any  number,  and 
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on  whether  there  is  a  single  QoS  dimension  or  multiple.  We  have  the  following  four 
problem  classes: 


•  Single  Resource  and  Single  QoS  Dimension:  SRSD 

•  Single  Resource  and  Multiple  QoS  Dimensions:  SRMD 

•  Multiple  Resources  and  Single  QoS  Dimension:  MRSD 

•  Multiple  Resources  and  Multiple  QoS  Dimensions:  MRMD 


In  this  thesis,  we  are  going  to  address  the  SRidD  and  MRMD  problems  directly. 
Since  MRMD  is  a  superset  of  the  other  problem  classes,  we  could  have  chosen  to 
address  that  class  only,  but  it  turns  out  that  there  are  significant  computational 
benefits  to  addressing  SRMD  separately.  We  have  developed  efficient  schemes  for 
SRMD  that  are  not  easily  achievable  for  MRMD.  The  schemes  we  have  for  SRMD 
readily  lead  us  to  a  QoS-driven  single  resource  allocation  when  only  a  single  resource 
is  of  concern  (either  it  is  the  only  resource  under  consideration,  or  it  is  relatively  more 
scarce  and  other  resources  are  abundant).  For  instance,  these  schemes  can  be  used 
for  QoS-driven  disk,  memory,  network  bandwidth  as  well  as  for  processor  scheduling. 

We  treat  the  two  remaining  classes  only  indirectly:  an  SRSD  problem  is  also  an 
SRMD  problem  and  an  MRSD  problem  is  also  an  MRMD  problem. 


4.2  Problem  Complexity 


This  combinatorial  problem  could  also  be  formulated  as  follows.  Let  kh,...,  khq-i  be 
an  enumeration  of  the  quality  space,  Qi,  for  task  3^.  Let  piji , ,  PijNij  be  an  enumer¬ 
ation  of  the  resource  usage  choices  (tradeoffs  among  different  resources)  associated 
with  Kij  for  Ti,  where  Nij  is  the  number  of  such  resource  usage  choices.  (In  particular 
we  should  always  have  pijk  |=j  Kij.) 

Let  Xijk  =  1  if  task  Ti  has  been  given  quality  point  Kij  and  resource  consump- 
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tion  pijk,  and  Xijk  —  0  otherwise.  We  can  now  reformulate  system  2.1  as: 

n  IQtl 

maximize  EEE 

i=l  j=l  fe— 1 
n  \Qi\  ^ij 

subject  to  EEE  ^ijkPijki  —  1  ^  !)•••) 

i=l  j=\  fe=l 
IQ«I  Nij 

'y  ^  y  ^  ^ijk  ^  l,...,n., 

j=l  k=l 

Xijk  ^  {0?  l})  i  =  1, . . .  ,n,  j  =  1, ,  \Qi\ ,  k  =  1, . . . ,  Nij. 

■  (4.1) 

The  three  constraints  express  the  following.  The  first  one  ensures  that  we  will  not 
oversubscribe  resources.  The.  second  ensures  that  we  assign  at  most  one  quality- 
resource  allotment  per  task.  The  third  one  expresses  the  boolean  nature  of  the  choice 
variables  Xijk- 

Note,  that  pijke  is  just  the  Ith.  coordinate  of  the  vector  pijk- 
Therefore  all  the  instances  of  our  problem  can  be  viewed  as  special  cases  of  the 
general  integer  or  nonlinear  programming  problems. 

Proposition  1  SRSD,  SRMD,  MRSD,  and  MRMD  are  all  NP-hard  problems. 

Proof  Since  SRSD  is  a  special  case  of  the  other  three,  we  only  have  to  show  that 
SRSD  is  NP-hard. 

For  SRSD,  we  have  m  =  Nij  =  1  and  thus  k  =  i  —  1.  System  (4.1)  becomes 

n  \Qi\ 

maximize  EE 

i=l  j=l 
n  IQii 

subject  to  V  Y)  XijiPijii  < 

i=ij=i  (4.2) 

IQil 

y )  Xiji  ^1)  i  1)  •  •  •  > 

i=i 

Xiji  €  {0, 1},  i  =  1, . . . ,  n,  j  =  1, ... ,  \Qi\ . 

The  0-1  Knapsack  Problem  is  known  to  be  NP-hard  [34].  It  can  be  described  as 
follows.  Given  a  set  of  n  items  and  a  knapsack  of  capacity  c,  with  pi  and  Wi  the  profit 
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and  weight  of  item  i  respectively,  select  a  subset  of  the  items  so  as  to 

n 

maximize  Y^^PiXj 
%=1 

n 

subject  to  E  WiXi  <  c  (^•^) 

i~l 

a;j6{0, 1},  i  =  l, 

We  can  therefore  reduce  the  0-1  Knapsack  Problem  to  SRSD  by  setting 

=  {(1)} 

MQi)  =  Pi 

^max  ^  ^ 

Pilll  =  Wi 


and  have  the  0-1  Knapsack  Problem’s  Xi  represented  by  Xm  in  the  SRSD  case.  Thus 
SRSD  is  as  least  as  hard  as  the  0-1  Knapsack  problem  and  therefore  it  is  NP-hard.O 

4.3  Algorithm  Design  Issues 

As  just  shown  and  also  in  [30]  [28],  the  QoS  management  optimization  problems  are 
NP-hard.  As  a  consequence,  there  are  no  optimal  solution  techniques  other  than 
a  (possibly  complete)  enumeration  of  the  solution  space.  On  the  other  hand,  QoS 
management  calls  for  on-line  solutions  as  the  optimization  module  will  ideally  be  in 
the  heart  of  an  admission  control  and  adaptive  QoS  management  system.  Therefore 
the  goal  is  to  strike  the  right  balance  between  solution  quality  and  computational 
complexity. 

For  more  than  two  decades,  many  researchers  from  the  fields  of  mathematics, 
computer  science  and  operations  research  have  been  working  on  the  combinato¬ 
rial  optimization  and  solving  NP-hard  problems.  There  are  three  algorithmic  ap¬ 
proaches  [1]  [34]  that  have  been  well  studied  and  widely  used: 

Enumerative  methods 

that  are  guaranteed  to  produce  an  optimal  solution  [13]  [14], 
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Approximation  algorithms 

that  run  in  polynomial  time  [50]  [15],  and 

Heuristic  techniques  (under  the  general  heading  of  local  search) 

that  do  not  have  a  priori  guarantee  in  terms  of  solution  quality  or  running  time, 
but  provide  a  robust  approach  to  obtaining  a  high-quality  solution  to  problems 
of  a  realistic  size  in  reasonable  time  [1] . 

An  important  attribute  is  the  incremental  and  state-reuse  property  of  a  scheme, 
so  as  to  avoid  having  to  completely  redo  expensive  computations  to  accommodate  the 
dynamic  arrival  and  departure  of  tasks.  Also,  we  ensure  that  all  algorithms  should  be 
formulated  so  that  the  the  search  for  an  optimal  solution  can  be  terminate  at  any  time 
while  still  reaching  a  feasible,  but  sub-optimal  and  hopefully  good,  solution.  These 
two  properties  are  essential  for  an  algorithm  to  be  used  in  an  online  (or  near-online) 
environment. 

Therefore  a  series  of  schemes  have  been  developed  that  give  approximation,  ap¬ 
proximation  with  bound,  and  exact  solutions,  with  increased  asymptotic  computa¬ 
tional  complexity.  These  algorithms  use  various  optimization  techniques  including 
linear  and  nonlinear  programming,  constraint  relaxation,  basic  dynamic  program¬ 
ming,  branch-bound,  advanced  dynamic  programming  with  addition  of  dominance 
rules,  direct  and  local  search  schemes. 

,It  will  be  necessary  to  conduct  extensive  empirical  studies  to  evaluate  the  practical 
performance  of  these  algorithms  when  deployed  under  different  system  setups  and  task 
profiles.  For  instance,  the  systems  to  which  QoS  management  optimization  engine 
could  be  deployed  could  range  from  an  end-node  multi-media  workstation,  small  or 
medium  scale  proxy /transceiver^  servers,  medium  or  large  (with  firewall  and  routing 
capability)  gates  [23],  and  on-demand  media  (news,  video,  stock  quote,  game)  servers. 
These  studies  allow  comparison  of  the  relative  performance  of  the  the  algorithms  and 
answer  questions  such  as  whether  algorithms  are  robust  [44]  enough  to  cover  multiple 
cases,  or  whether  combination  algorithms  might  prove  useful.  In  the  latter  case,  the 
QoS  management  optimization  engine  could  fire  an  algorithm  based  on  the  particular 
data  instance  exhibited  by  the  profiles  of  application/user  sessions  in  the  system. 


^Data  distillation  for  low-link-speed  mobile  or  other  clients  for  instance. 
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Another  important  issue,  which  is  policy-dependent  but  would  affect  the  actual 
algorithm  design,  is  the  stability  of  the  task  quality  assigned  to  existing  tasks  in  the 
system'.  In  the  case  where  policy  requires  that  quality  not  degrade  for  certain  tasks, 
some  algorithms  might  not  be  suitable  ,  while  others  might  be  more  appropriate. 

4.4  Structure  Composition  of  Resource  Utility 

In  Section  2.5  we  explained  that  no  function  relationship  can  be  described  between 
quailty  and  resource.  Similarly,  there  is  no  direct  function  relationship  present  be¬ 
tween  resource  and  utility,  as  utility  is  a  function  of  quality.  Moreover,  due  to  the 
multi-dimensional  and  potentially  subjective  nature  of  quality  of  services,  there  is 
often  no  complete  ordering  among  quality-of-service  points,  even  for  individual  tasks. 


resource 


Figure  4.2:  Scatter  of  Resource  and  Utilities 

As  in  the  case  of  resource  and  quality,  only  a  scatter  plot  for  R  and  U  can  be 
drawn;  an  illustration  is  shown  in  Figure  4.2.  Therefore  some  structural  composition 
or  processing  is  required  for  those  algorithms  that  call  for  mapping  from  resource 
to  utility  as  heuristic.  Fortunately,  an  R-U  (resource  to  utility)  function/graph  can 
constructed  for  each  task  through  QoS  Profile  and  Resource  Profile.  Such  an  R-U 
graph  can  be  drawn  by  listing  each  valid  quality  point’s  resource  usage(s)  and  its 
corresponding  utility  through  the  steps  described  below. 

Recall  that  given  a  resource  allocation  to  a  task,  one  could  use  the  resource  to  im¬ 
prove  different  QoS  dimensions,  which  could  therefore  lead  to  different  utility  values. 


Structure  Composition  of  Resource  &  Utility  41 


But  the  most  valued  QoS  point  for  each  resource  value  can  be  picked  (as  depicted  in 
Figure  4.3,  assume  that  Ui  >  U2)  as  intuitively,  we  certainly  want  to  assign  resources 
to  those  quality  points  with  the  highest  utility  value. 

hi(r) 


/  \ 

I  \ 


Figure  4.3:  Resource-Utility  Structure  Composition 


We  therefore  can  define  a  function  pi  :  R  -^IRhy 

gi{r)  =  max{  Ui{q)  \  r  q}  (4.4) 

and  define  hi  :  R  ViQi)  (see  Figure  4.3)  to  retain  the  quality  points  associated 
with  the  utility  value  gi{r): 

hi{f)  =  {Q^Qi\  Ui{q)  =  giir)  Ar\=iq}  (4.5) 

Then  an  R-U  graph  can  be  generated  for  each  task,  each  of  which  would  be  a  step 
function  (perhaps  with  multiple  level  of  steps). 

When  utility  is  defined  as  profit,  functions  gi  and  hi  above  will  be  defined  as 

gi{r)  =  max{  Ui{q,  r)  |  r  |=i  g  }  (4.6) 


hi{r)  =  {qeQi\  Ui{q)  =  Pi(r)  A  r  |=j  g } 


(4.7) 
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4.5  Chapter  Summary 

This  chapter  classify  our  problems  into  four  subcategories,  two  of  which  will  be  given 
direct  treatment  in  the  following  chapters.  Complexity,  algorithm  design  issues  and 
structure  composition  was  discussed. 

The  taxonomy  of  the  problem  space  was  defined  based  on  our  quality  optimiza¬ 
tion  model.  The  following  four  classes  of  problems  are  identified:  Single-Resource 
Single  QoS  Dimension  (SRSD),  Single-Resource  Multiple  QoS  Dimensions  (SRMD), 
Multiple-Resource  Single  QoS  Dimension  (MRSD)  and  Multiple-Resource  Multiple 
QoS  Dimensions  (MRMD).  All  these  four  problem  classes  are  then  shown  to  be  NP- 
hard.  Enumerative  techniques,  approximation  algorithms  or  heuristics  must  therefore 
be  applied  to  solve  our  optimization  problem.  Since  a  simple  functional  relationship 
does  not  exist  between  quality  and  resource  in  our  case,  a  structnral  composition 
processing  scheme  is  introduced  that  produces  resource-utility  heuristics  for  the  ap¬ 
proximation  algorithms  to  be  presented  in  Chapter  5  and  6. 


Chapter  5 

SRMD  Algorithms 


In  this  chapter  we  focus  on  the  SRMD  problem  where  just  one  resource  under  man¬ 
agement.  We  present  two  near-optimal  algorithms  to  solve  this  problem.  The  first 
yields  an  allocation  within  a  known  bounded  distance  from  the  optimal  solution,  and 
the  second  yields  an  allocation  whose  distance  from  the  optimal  solution  can  be  ex¬ 
plicitly  controlled  by  the  QoS  manager.  We  compare  the  asymptotic  performance  of 
the  approximation  algorithms  to  an  exact  algorithm  which  in  turn  is  designed  using 
dynamic  programming.  Their  practical  performance  evaluations  will  be  presented  in 
Chapter  7. 

5.1  An  Optimal  Solution  Scheme 

Assume  that  the  resources  are  allocated  in  units  of  r^^/P  for  some  integer  P.  If,  for 
example,  P  =  100  this  would  mean  that  allocation  is  in  integer  percentage.  Under  this 
assumption,  we  can  characterize  the  structure  of  the  optimal  solution  and  recursively 
define  its  value  as  follows. 

Denote  by  v{i,p)  the  maximum  utility  achievable  when  the  first  z  of  n  tasks  are 
considered  with  resource  r^^^pjp  available  for  allocation.  We  can  describe  v{i,p)  in 
terms  of  —  1,  •)  by  considering  all  allocation  choices  for  the  zth  task; 

v{i,p)=  max  {gi{p')+v{i- I, p-p')}  (5.1) 

p'e{o,...,p} 

Obviously,  u(0,p)  =  0.  As  optimization,  the  set  of  interesting  p'  values  to  consider  is 
in  fact  just  all  the  (starting)  discontinuity  points  of  gi  (see  Definition  4.4). 


43 


44  SRMD  Algorithms 

Therefore  v{n,  P)  will  be  the  maximum  utility  achievable  by  allocating  up  to 
to  the  n  tasks,  i.e.,  the  best  allocation  overall. 

Based  on  Equation  5.1,  the  following  algorithm  srmd  can  be  constructed  through 
dynamic  programming.  Let 


denote  the  utility  function  gi^s  discontinuity  points  in  increasing  w-order,  and  qos{i,p) 
the  list  of  QoS  allocation  choices  for  Ti  through  T,  towards  v{i,p). 

srmd(n,  P,Ci,...,Cn) 

1.  for  p  =  0  to  P  do 

2.  qos{0,p)  :=  nil 

3.  u(0,p):=0 

4.  r(0,p)  :=  0 

5.  for  i  =  1  to  n  do 

6.  qos{i,  0)  :=  nil 

7.  'y(i,0)  :=  0 

8.  for  p  =  1  to  P  do 

9.  u*  :=  0 

10.  r*  ;=  0 

11.  f  :=  0  ^ 

12.  for  j  =  1  to  \Ci\  do 

13.  if  {vij  >  p  or  hi{rij)  <  g™’®)  break 

14.  u:=Uij  +  v(i-l,p-rij) 

15.  if  u  >  M*  then 

16.  u*  :=  u 

17.  r*  :=  ry 

18.  j*  :=  j 

19.  qos{i,p)  qos{i  —  l,p  -  ry»)  concat  [hi{rij»)] 

20.  v{i,p):=u* 

21.  r{i,p):=r* 

22.  p  :=  - 

23.  for  i  —  n  downto  1  do 
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24.  resource{i)  :=  r{i,p) 

25.  u{i):=v{i,p) 

26.  p  :=p  —  resource{i) 

27.  return  v{n,  P),  qos{n,  P)  resource{l),  . . .  ,resource{n), 

u{l),  u{2)  -  «(1),  . . .  ,u{n)  -  u{n  -  1) 

The  result  v{n,  P),  the  utility  accrued  when  100%  of  the  resource  is  available,  is 
optimal.  Let  L  =  max^^i  \Ci\.  The  time  complexity  of  the  algorithm  is  0{nLP)  or 
OinP"^),  which  is  pseudo-polynomial. 

One  of  the  plus  sides  of  this  scheme  (also  true  for  the  MRMD  scheme  described 
in  Chapter  6)  is  its  incremental  and  state-reuse  property  in  which  when  a  new  task 
arrives,  previous  results  can  be  directly  reused  to  avoid  the  expensive  recomputation 
of  the  complete  new  task  set. 

When  the  session  length  information  of  tasks  are  available,  the  task  lists  are 
generally  ordered  in  decreasing  session  length  order,  so  when  a  task  T„  finishes  and 
departs  the  system  (and  therefore  releases  some  resources),  the  result  for  Tj,  z  = 
1, . . . ,  n  —  1  is  already  computed  and  kept  in  the  system,  that  could  be  reused  to  make 
a  quick  decision  (not  necessarily  to  be  optimal  especially  when  a  stability  policy  is  in 
use)  on  which  tasks’  qualities  could  be  improved. 

When  a  priority-based  policy  alone  is  emphasized,  the  task  list  to  be  fed  into  the 
algorithm  will  be  in  non-increasing  order  of  task  priorities. 

Algorithm  srmd  could  be  a  practical  method  for  QoS-driven  single  resource  allo¬ 
cation,  such  as  processor  scheduling  in  operating  systems  which  support  QoS.  The 
algorithm,  with  minor  change,  would  be  suitable  to  deal  with  the  stability  problem 
when  a  user  prefers  (or  a  policy  requires)  a  relative  consistent  quality. 


5.2  An  Approximation  Scheme 

By  constructing  the  convex  hull  for  each  of  gi  (see  Definition  4.4)  functions  we  get 
piece- wise  linear  relaxation  functions  g°,  i  =  1, . . .  ,n.  The  gradients  of  of  g°  can  be 
used  as  a  heuristic  to  allocate  resources  among  these  tasks.  Let 
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be  the  utility  function  gi’s  discontinuity  points  in  increasing  r-order  (therefore  in¬ 
creasing  n-order  as  well).  We  will  refer  to  these  lists  as  r-n-pair  lists.  Denote  by 
the  current  remaining  resource  capacity  after  certain  resource  has  been  allocated; 
s_list[i].t,  sJist[i].r,  sJist[2].M  the  task  id,  the  associated  r- value  and  "W- value  of  the 
corresponding  r-u-pair  list;  and  r[i]  the  resource  allocated  for  T*. 

asrmdl (n,Ci, . . .  ,Cn) 

1.  for  i  =  1  to  n  do 

2.  Cl  :=  convex_hull_frontier(C'i) 

3.  u[i]  :=  0 

4.  r[i]  ;=  0 

5.  sJist—  merge(C'(, . . . ,  C' ) 

7.  u:=0 


8. 

for  j  =  1  to  do 

9. 

i  :=  sJist[j].t 

10. 

P  =  sJist[j].r  —  r[i] 

11. 

if  (yd  <  r^)  then 

12. 

yC  _  p 

13. 

r[i]  :=  sJist[j].r 

14. 

u[i]  :=  sJ.ist[j\.u 

/*  Update  allocation  info  for  Ti.  */ 

15. 

else 

16. 

breeik 

17. 

for  i  =  1  to  n  do 

18. 

q[{\  :=  hi{r[i]) 

/*  See  Definition  f.S.  */ 

19. 

u  :=u  +  u[i\ 

20. 

return  (u,5[l], . . . ,g[n], 

r[l],...,r[n], M[n]) 

Note  that  each  q[i]  provides  a  set  of  quality  choices  from  which  T*  (its  user, 
manager)  could  choose  to  make  further  QoS  tradeoffs. 

Notice  that  in  implementation,  we  actually  replace  “break”  in  line  16  with  continue 
(i.e.,  let  the  loop  continue  when  condition  at  step  11  does  not  hold).  This  means 
that  after  the  optimality  condition  (to  be  described  shortly)  is  violated,  the  residual 


Ail  Approximation  Scheme  47 


capacity  (r^)  will  be  greedily  filled.  The  continuation  can  be  thought  as  a  post- 
optimization  process.  The  error  bound  property  to  be  proved  below  holds  for  either 
case. 

Let  L  =  maxf^i  \Ci\.  After  the  procedure  convex.hulLfrontier^  (which  takes  time 
0{nL))  a  convex  hull  frontier  with  non-increasing  slope  segments  (piece- wise  concave) 
is  obtained  for  each  task.  The  segments  are  merged  at  step  5  using  a  divide-and- 
conquer  approach  with  log2  n  levels,  each  level  having  nL  comparisons.  Merging  thus 
takes  time  0(nL log n).  Steps  8  through  16  require  0(|sJ2st|)  =  0{nL).  Steps  17 
through  19  take  0{n).  The  total  running  time  of  the  algorithm  is  thus  O(nLlogn)  -|- 
0{nL)  =  0{nL\ogn). 

Denote  by  5i  the  maximum  utility  difference  between  adjacent  discontinuity  points 
of  C'i,  i.e.,  the  largest  increase  in  utility  for  task  Ti  on  the  convex  hull  frontier.  Let  x  = 
maxf^i  5i.  Denote  by  17opt  the  optimal  utility  result  and  t/asrmdi  the  approximation 
result  obtained  by  algorithm  asnndl. 

Theorem  1  Uasrmdl  is  within  X  of  U opt,  i-O.  Uopt  —  X  <  Uasrmdl  <  Uopt- 


Proof  Note  first,  that  if  the  residual  resource,  r^,  ends  up  being  zero  before  execut¬ 
ing  “break”  at  step  15  (or  if  j  reaches  the  end  of  \sJist\),  then  the  solution  found 
is  in  fact  optimal  based  on  the  Kuhn-Tucker  condition [43],  as  each  g°  (represented 
by  Cl  in  asrmdl)  is  essentially  a  piece- wise  concave  function. 

Algorithm  asrmdl  produces  a  utility  value,  t/asrmdi,  which  is  feasible.  Therefore 

we  have  C7asrmdl  —  Uopt- 

Suppose  that  convex  hull  frontier  segments  (ordered  and  stored  in  sJist)  axe 
consecutively  used  (with  corresponding  quality  upgrade  and  added  utility)  until  the 
first  segment,  s,  is  found  that  requires  more  resource  than  residual  resource  capacity 
to  realize  the  extra  utility  at  the  end  of  the  segment  s  (remember  that  the  convex 
hull  segments  are  imaginary  linear  relaxation  of  the  real  utility  functions). 

Let  the  two  end  points  of  the  critical  segment  s  be  {rsi,Usi)  and  (r^j+i ,  Wsi+i)  in  Cf 
Based  on  the  Kuhn-Tucker  condition  and  the  Dantzig[9]  upbound  (combined  referred 
to  as  the  Optimality  Condition),  we  have 


opt 


^  f^asrmdl  (X  '^si) 


'^si 

si+1  si 


^Overmars  k  Leeuwen’s  [42]  algorithm,  or  simply  the  quickhull  [45]  or  Graham-Scan  [7]  when  Q 
are  not  pre-sorted. 
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<  U^rmdl  +  (rsi+i-rsi)-^'  """ 

sz+1  ^  si 

f^asrmdl  H“  '^si 

and  we  know  that  Usi+i  -  u^i  <  x,  therefore  Uo-pt  -  t4srmdi  X-  □ 

Remark:  To  give  a  feel  for  how  tight  the  bound  is  from  below,  examine  two  cases 
(see  Figure  5.1)  when  the  results  are  suboptimal.  The  reason  for  the  first  case  is 


Figure  5.1:  Suboptimal  Cases 

sub-optimality  is  due  to  the  convex  hull  approximation  error  (where  one  or  more 
intermediate  utility  points  are  bridged  and  removed  when  we  construct  (or  G(), 
from  Qi  (or  Cj);  the  reason  for  the  second  case  is  the  consequence  of  the  greedy 
heuristic  (no  costly  backtracking  after  optimal  condition  is  violated)  near  the  end  of 
the  asrmdl  optimization  process. 

Case  1.  When  interior  (intermediate)  points  are  bridged  over  and  dominated  by 
the  critical  convex  hull  segment  s  (see  Figure  5.1(a)). 

Let  the  inferior  point  bridged  over  by  s  with  the  largest  utility  be  {rj,Uj),  where 
j  >  si  in  the  original  Q  list  of  T*.  Further  assume  that  -  r^i  <  and  there  are  no 
more  elements  left  in  sJist.  Then  when  asrmdl  stops  and  reports  the  achieved  utility 
of  f/asrmdi,  which  excludes  (rsj+i,Msj+i),  the  optimal  is  in  fact  [/opt  =  Uasvmdi+{uj-Usi). 
Since  Uj  Ugi  <  X)  f^asrmdl  t^opt  X- 

^Except  in  the  degenerate  case  where  x  =  0,  and  Uopt  -  f/asrmdl  =  X  =  t/opt  =  C/asrmdl  =  0. 
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Case  2.  When  and  there  are  {rsj,Usj)  and  {rsk,Usk)  ^  in  sJist,  where 

sj,  sk  >  si,  and  their  slopes  are  lower  than  that  of  ,  but  {r^—rgi)  <  Vgj,  {r^—rgi)  < 
Tsk,  rgj  +  rgk  <  rS  and  {ugj  +  Ugk)  >  ««  (Figure  5.1(b)).  By  the  Dantzig  bound,  the 
t4srmdi  would  be  Well  within  x  as  well. 

Although  asrmdl  is  a  polynomial  approximation  algorithm  with  a  describable  and 
potentially  small  error  bound  from  the  optimal  result,  the  bound  is  not  controllable. 
Section  5.3  presents  another  polynomial  scheme  with  a  controllable  error  bound. 


5.3  A  Polynomial  Scheme  with  Controllable  Bound 

The  algorithm  asrmd2  to  be  described  will  give  an  approximate  quality  and  resource 
allocation  which  is  guaranteed  to  have  a  maximum  relative  error,  e,  where  0  <  e  <  1 
is  a  user-specified  value.  A  relative  error  of  e  means  that  the  utility  ?7asrmd2  found  by 
the  algorithm  satisfies 

(1  ^^Uopt  —  f^asrmd2  —  f4)pt 
where  Uopt  is  the  optimal  utility. 

Before  presenting  asrmd2,  let  us  define  some  data  structures  and  operations  to 
be  used  in  the  algorithm.  All  utility  function  p,’s  discontinuity  points  are  listed  in 
increasing  u-order  as 


where  is  the  first  element,  and  referred  to  as  r-tt-pair  lists.  We  also  define  the 
following  addition  operation  for  r-w-pair  lists  and  r-w-pair  elements. 


/  /wi  4- 

\Vri  +  ry 


Uk  +  \ 

rk  +  r)  / 


Note,  that  this  operation  produces  a  new  r-w-list  that  is  sorted  non-decreasingly  in 
«-value.  Prom  now  on  such  sorting  will  be  assumed. 

Let  A  and  B  be  r-«-pair  lists.  The  procedure  comhine-and-merge  will  combine  A 
and  B  into  a  single  r-w-pair  list. 

®Or  a  single  element  with  higher  utility  value  than  Ugi  given  -I-  This  case  is  not  shown  in 
Figure  5.1 
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combine_and_merge(i4,  B) 

1.  foreach  bi  €  B 

2.  Aj  :=  A  +  bi  /*  Aj  is  now  increasing  in  u-value.  */ 

3.  (7  ;=nierge(Ai,...,Afc) 

4.  return  C 


where  k  —  \B\,  and  Aj,  1  <i  <  k,  are  intermediate  r-tt-pair  lists. 


Steps  1  and  2  takes  0(|A|  |5|),  step  3  takes  0(|A|  |B|  log  |5|)  if  we  do  it  through 
divide-and-conquer  and  merge  lists  in  pairs  recursively.  So  combine-and^merge  is 
0(1  A|  |B|log|B|). 


The  procedure  resourcesieve  trims  those  r-w-pair  elements  of  list  L  =  (^  , . . . ,  j  ^ 

which  do  not  satisfy  r  <  and  those  elements  that  are  inefficient.  By  inefficient 

we  mean:  for  each  element  and  element  from  L,  if  rj+i  <  n  (and  Ui  <  Uj+i 

since  elements  are  sorted)  then  is  inefficient  and  should  be  removed  from  L.  In¬ 
tuitively,  we  only  want  to  keep  those  choices  that  use  less  resource  while  achieving 
the  same  or  higher  utility.  The  procedure  takes  0(|L|). 


resource_sieve(L, 

1.  i:=l 

2.  while  i  <  \L\  do 

3.  if  Tj+i  >  then 

4.  Remove  L 

5.  else 

6.  while  i  >  1  euid  fj+i  <  ri  do 

7.  Remove  from  L 

8.  i  :=i  —  l 

9.  i  ■.=  i-\-l. 

10.  if  Tj  >  then 

11.  Remove  from  L 

12.  return  L. 


Procedure  representativeJist  trims  the  r-u-paix  list  further  in  0{\L\)  by  removing 
elements  that  are  too  close  to  other  element  in  terms  of  tt-value.  That  is,  for  each 
adjacent  and  from  L,  if  (wj+i  —  itj)/Mj+i  <  5,  then  can  be  presented 
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by  with  a  discrepancy  of  at  most  5  w.r.t.  the  w-value  of  ,  and  therefore 

pgjj  130  removed  from  L. 

Vi+iJ 

representativeJist(L,  5) 

1-  -  ((“;)) 

2.  u*  :=  Ui 

3.  for  i  =  2  to  |L|  —  1  do 

4.  if  {u*  <  Ui{l  -  S))  then 

5.  append  to  L' 

6.  u*  :=  Ui 

7.  return  L' 

Given  the  above  procedures,  the  bounded  approximation  scheme  can  be  con¬ 
structed  as  follows.  For  the  sake  of  simplicity  of  the  complexity  analysis  to  follow,  we 
introduce  some  intermediate  lists  Lia,  Lib  and  Li. 

asrmd2(C'i, ...,  Gra,  e) 


2.  S  :=  s/n 

3.  for  z  =  1  to  n  do 

4.  Lia  :=  combine^nd_merge(L,_i,  Cj) 

5.  Lib  :=  resource_sieve(Lja, 

6.  Lj  :=  representativeJist(Li6,  (5) 

7.  let  be  the  element  with  the  largest  utility  value  in 

8.  return 

Without  resourcesieve  and  representativeJist  the  length  of  the  list  obtained  at 
step  4  in  asrmd2  could  increase  exponentially.  We  will  show  that  with  those  steps, 
the  length  of  Li  will  be  bounded  by  +  2J ,  where  u^p  and  rtiow  are  easily 

determined  from  Q. 

Lemma  1  Given  two  sorted  r-u-pair  lists  A  and  B,  combine_and_merge  generates  a 
sorted  r-u-pair  list  which  contains  all  the  possible  combinations  of  a  choice  element 
from  A  and  a  choice  element  from  B. 
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Proof  Since  A  is  sorted,  each  Ai  in  step  2  of  combine-and-merge  maintains  its 
order.  Moreover  Ai  contains  all  new  combinations  of  choices  that  can  be  generated 
by  selecting  one  choice  from  A  and  the  other  as  k  from  B.  Therefore  after  the  loop  at 
step  1  of  combine-and-merge  finishes,  all  possible  combinations  of  one  element  chosen 
from  A  and  one  element  chosen  from  B  are  stored  in  Ai,  where  1  <  i  <  \B\.  The 
merge  at  step  3  will  therefore  generate  a  single  combined  sorted  list.  □ 

Theorem  2  The  approximation  of  asrmd2  is  within  a  bound  of  e  w.r.t.  the  optimal. 

Proof  If  we  were  not  to  have  the  trimming  operations  resourcesieve  and  represen¬ 
tative-list  in  steps  5  and  6  (denote  such  lists  generated  without  trimming  by  Lf),  we 
could  prove,  based  on  Lemma  1,  by  induction  on  i  that  combine-and-merge  at  step  4 
would  list  all  the  possible  r-M-pair  combinations  for  i  tasks.  It  would  then  lead  us  to 
an  optimal  solution  at  the  expense  of  exponential  time  complexity  in  general,  since 
the  length  of  L?  would  grow  exponentially. 

With  trimming  that  removes  from  L*  every  element  that  is  greater  (in  terms  of  r- 
value)  than  r^^^  in  step  5,  and  the  trimming  in  step  6,  the  property  that  every  remain 
element  in  Li  is  a  member  of  the  complete  solution  space  is  maintained.  Therefore, 
the  r-w-pair  retmmed  in  step  7  is  indeed  one  valid  allocation  scheme.  It  remains  to 
show  that  the  m- value  of  the  returned  pair  is  not  smaller  than  1  —  e  times  an  optimal 
solution. 

Since  resource-sieve  at  step  5  only  throws  away  invalid  elements  that  violate  the 
resource  constraint,  or  those  that  for  sure  cannot  contribute  toward  the  optimal  solu¬ 
tion,  any  error  will  only  be  caused  by  representative-list.  So  it  remains  to  be  shown 
that  the  relative  error  caused  by  representative-list  is  bounded. 

When  Li  is  trimmed  by  representative-list,  a  relative  error  of  at  most  6  (or  e/n) 
is  introduced  between  the  representative  values  remaining  in  the  list  and  the  values 
before  the  trimming.  By  induction  on  i,  it  can  be  shown  that  for  every  element 
in  Li  with  r°  <  there  is  an  in  Li  such  that 

{I  —  s/ny'u°  <u  <u° . 

If  (^°?*)  ^  LI  denotes  an  optimal  solution  to  the  SRMD  problem,  then  there  is  an 

€  Li  such  that 

(1  -  £/n)”t/opt  <U<  [/opt 
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The  with  the  largest  u  is  the  value  returned  by  representative Jist  and  u  =  17asrmd2- 
The  value  of  (1  —  e/n)”  increases  with  n,  as  it  can  be  shown  that 

>0  for  a;  >  1, 

dx  \  xj 

so  that  n>  1  implies  1  —  e  <  (1  —  e/n)",  and  therefore 

(1  £)Uopt  ^  f^asrnid2  ^  Uopt 

That  is,  the  result  returned  by  representative-list  has  a  maximum  relative  error  of 
less  than  e. 

We  will  show  that  the  algorithm  is  of  polynomial  time  complexity.  Begin  by 
investigating  Li  in  representative-list.  After  trimming,  successive  elements  j  and 
(r'+j)  must  satisfy  Ui  <  that  is 

Uj+l  1 

Ui  1  —  5 

as  illustrate  in  Figure  5.2. 


low  ^up 


^  utility 
(log  scale) 


Figure  5.2;  Successive  Elements  in  Li  After  representative-list 


Let  /  =  1/(1  -  (5)  and  K  =  Llog/(uup/«iow)  +  2J,  where  Uup  >  0  is  the  u  in  step  7 
of  asrmd2  and  Wiow  >  0  is  the  smallest  utility  value,  among  all  tasks,  other  than  0. 

Lemma  2  There  are  at  most  K  elements  in  each  Li  of  step  6  of  asrmd2. 

Proof  Not  counting  the  first  element  (whose  tt- value  is  zero),  representative-list  at 
step  6  removes  elements  that  differ  in  u- value  from  each  other  by  a  factor  of  less 
than  /.  Therefore,  the  number  of  elements  in  Li  will  be  at  most 

1  +  max{  A:  >  0  I  /^ttiow  <  Wup  }  =  1  +  Llog/(^up/^tiow)  +  Ij 

=  [logy  (liup/uiow)  ”1”  2j 

=  K. 


□ 
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Theorem  3  asrmd2  is  a  polynomial  approximation  for  SRMD. 

Proof  Since  steps  4  through  6  in  asrmd2  are  all  polynomial  in  the  lengths  of  the 
lists  they  handle,  and  since  step  6  by  Lemma  2  reduces  the  number  of  elements  to 
less  than  K,  it  remains  to  be  shown  that  the  number  of  elements  after  steps  4  and  5 
are  bounded. 

For  step  5  this  is  trivial  since  it  reduces  the  number  of  elements.  For  step  4,  the 
number  of  elements  grows  by  a  factor  of  \Ci\,  so  the  number  of  elements  after  step  4 
is  bounded  by  where 

max  \Ci\ 

2=1,.. .,n 

The  total  number  of  steps  in  asrmd2  therefore  is  bounded  by 

cnKC^^^  ^  cnC-""  [log/i/up/niow)  +  2j 

CuC  £:/Ti)('^up/'^low)  2J 

~  L  ^ 

for  some  constant  c  >  0.  So  the  running  of  asrmd2  can  be  obtained  as 

0{nLiL\ogL)  =  0{nKL\ogL) 

=  O(nMn-^-IlogL) 

'^low  ^ 

=  0(n2ln^^LlogL-) 

'Umin  S 

=  0(n^L  Inn  log  L/e) 

=  0(n^L  log  n  log  L/s) 

where  Wmax  is  the  maximum  utility  and  u^am  is  the  minimum  utility  in  the  system. 
Therefore  it  is  polynomial  in  time  in  terms  of  the  input  n,  L  and  1/e.  And  it  is  clear 
that  the  algorithm  is  polynomial  in  space  as  well.  □ 

The  analysis  of  asrmd2  is,  in  part,  modelled  after  [15]. 

5.4  An  Optimization  Example 

Here  we  present  a  simple  example  to  illustrate  the  asrmdl  algorithm.  Figure  5.3 
depicts  a  set  of  simplified  task  profiles  after  the  resource-utility  structural  composition 
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is  done  (see  definition  4.4  and  4.5).  In  this  case,  there  are  eight  tasks,  each  with  twenty 
different  quality  levels  specified,  and  a  total  available  resource  level  of  100. 


Figure  5.3:  Task  Profiles:  nuni_tasks=8,  r"*“'=100,  quality Jevels=20 


Figure  5.4  plots  the  approximation  data  points  for  each  task  after  the  con- 
vex-hulLfrontier  procedme  is  called  in  asrmd.  Note  the  drastic  reduction  in  the 
number  of  points.  Table  5.1  shows  the  resource  allocation  result  of  both  algorithm 
asrmdl  and  srmd,  which  happens  to  be  exactly  the  same. 


5.5  Chapter  Summary 

This  chapter  focused  on  solving  the  SRMD  (Single  Resource,  Multiple  QoS  Dimen¬ 
sion)  problem.  A  dynamic  programming  scheme  that  obtains  the  optimal  solution  is 
first  presented.  An  approximation  algorithm  is  then  presented.  This  computes  the 
convex  hull  frontier  on  the  processed  scatter  graph,  and  uses  a  greedy  method  to 
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Figure  5.4:  Convex  Hull  Frontier  Approximation 


traverse  the  highest  utility-per-resource  slope  at  any  given  allocation  step.  This  al¬ 
gorithm  has  the  property  that  the  distance  of  this  solution  from  the  optimal  solution 
is  bounded  and  that  the  bound  can  be  easily  determined  from  a  set  of  task  profiles. 
An  example  of  this  computationally  efficient  algorithm  is  also  given  to  illustrate  its 
key  steps.  Then,  a  polynomial  approximation  scheme  that  allows  the  specification  of 
a  maximum  distance  from  the  optimal  solution  is  presented.  This  algorithm  works 
by  keeping  a  set  of  evenly  interspersed  partial  solutions. 

We  will  study  the  practical  performance  of  these  algorithms  in  Chapter  7. 
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taskJd 

asrmdl 

srmd 

resource 

utility 

resource 

utility 

1 

2 

0.2689 

2 

0.2689 

2 

24 

0.6891 

24 

0.6891 

3 

18 

0.4842 

18 

0.4842 

4 

1 

0.2342 

1 

0.2342 

5 

1 

0.2121 

1 

0.2121 

6 

26 

0.6738 

26 

0.6738 

7 

27 

0.7513 

27 

0.7513 

8 

1 

0.2337 

1 

0.2337 

total 

100 

3.547 

100 

3.547 

Table  5.1:  Example  resource  allocations  of  asrmdl  and  srmd 
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The  problem  of  maximizing  system  utility  by  allocating  a  single  finite  resource  to 
satisfy  discrete  Quality  of  Service  (QoS)  requirements  of  multiple  applications  along 
multiple  QoS  dimensions  was  studied  in  Chapter  5  and  [27].  In  this  chapter,  we 
consider  the  more  complex  problem  of  apportioning  multiple  finite  resources  to  satisfy 
the  QoS  needs  of  multiple  applications  along  multiple  QoS  dimensions.  In  other  words, 
each  application,  such  as  video-conferencing,  needs  multiple  resources  to  satisfy  its 
QoS  requirements.  We  evaluate  and  compare  three  strategies  to  solve  this  class  of 
problem.  We  show  that  dynamic  programming  and  mixed  integer  programming  can 
be  used  to  compute  optimal  solutions  to  this  problem  but  exhibit  high  complexity. 
We  then  adapt  the  mixed  integer  programming  problem  to  yield  near-optimal  results 
with  smaller  running  times.  Finally,  we  present  an  approximation  algorithm  based 
on  a  local  search  technique  with  very  low  complexity.  Perhaps  more  significantly, 
the  local  search  technique  turns  out  to  be  very  scalable  and  robust  as  the  number  of 
resources  required  by  each  application  increases. 

6.1  An  Exact  Solution  Scheme 

The  solution  method  and  algorithm  described  in  this  section  can  be  viewed  as  an 
extension  of  the  dynamic  programming  algorithm  described  in  [27] .  The  scenario  we 
use  to  illustrate  the  algorithm  is  a  two-resource  (m  =  2)  case,  but  the  scheme  and 
results  described  below  extend  readily  to  higher  dimensions. 

The  challenge  here  is  to  extend  the  tabular  or  regular  dynamic  programming 
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scheme  to  the  case  of  multiple  resources.  As  in  the  single  resource  case,  each  allo¬ 
cation  is  in  units  of  size  and  r^^/Pa-  These  represent  the  smallest  possible 

allocation  of  each  resource  type,  and  Pj,  i  =  1, 2  determine  the  total  number  of  these 
resource  bundles.  When  Pi  =  P2  =  100,  for  instance,  this  would  mean  that  allocation 
is  given  as  an  integer  percentage  of  the  total  resource  available. 

For  the  two-resource  case,  the  structure  of  an  optimal  solution  to  the  problem  can 
be  characterized  as  follows. 

Denote  by  u(z,pi,p2)  the  maximum  utility  achievable  when  only  the  first  i  tasks 
are  considered  with  rJ““pi/Pi  units  of  resource  Pi  and  r^^p2/P2  units  of  resource  P2 
available  for  allocation.  Define  the  value  of  an  optimal  solution  recursively  in  terms 
of  the  optimal  solutions  to  subproblems  as 

v{i,Pi,P2)  =  ^^max^^^{gi{p[,p'^)  +  v{i  -  l,pi  -p'i,P2  -Pa)}  (6-1) 

In  analogy  with  the  single  resource  case,  v{n,  Pi,  P2)  will  be  the  maximum  utility 
achievable  given  n  tasks  and  r™®’'  of  resources.  The  set  of  interesting  p[  and  P2  values 
are  the  discontinuity  points  of  Pi. 

We  shall  use  the  following  notation  in  our  algorithm.  Let 


list  the  discontinuity  points  of  pi,  the  utility  function  associated  with  Ti  in  increasing 
M-order.  Let  r(i,pi,p2)  contain  the  corresponding  resource  allocations  that  yield 
^(bPi)P2)-  Let  qos{i,pi,p2)  be  the  list  of  QoS  allocations  choices  for  tasks  Ti  through 
Ti  that  result  in  v{i,pi,p2). 

Using  the  above  notation  and  based  on  Equation  (6.1),  an  exact  algorithm  can  be 
constructed  for  the  MRMD  problem  with  discrete  resource  bundle  allocations.  As  an 
illustrative  example,  the  following  formalizes  this  algorithm  for  m  =  2  and  general  n 
assuming  that  resources  have  been  divided  into  p,  i  =  1,2  bundles. 
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mrmd(n,  Pi,  P2,  Cl, . . . ,  Cn) 

/*  Initialization  */ 

1.  for  Pi  =  0  to  Pi  do 

2.  for  p2  =  0  to  P2  do 

3.  'i;(0,pi,p2)  :=0 

4.  r(0,pi,p2)  :=0 

5.  qos{0,pi,p2) '=nil 

/*  Dynamic  programming  */ 

6.  for  i  =  1  to  n  do  g 

7.  for  Pi  =  0  to  Pi  do 

8.  for  p2  =  0  to  P2  do 

9.  u*  ;=  0 

10.  r*  ;=  0 

11.  /:=0 

12.  for  j  =  1  to  Id  do 

13.  if  {rij  %  (pi,P2))  then 

14.  continue 

15.  u  :=  Uij  +  v{i-  l,pi  -  Tiji , p2  -  rij2) 

16.  if(M>M*)then 

17.  u*  :=u 

18.  r*  Tij 

19.  j*:=j 

20.  i;(i,Pi,P2)  :=  M* 

21.  r(i,pi,p2)  :=r* 

22.  qos{i,pi,P2)  qos(i  -  l,pi  -  riji,p2  -  rij2)  concat  [/ij(ry.)] 

/*  Unwind  and  retrieve  allocation  results  */ 

23.  (pi,P2):=r“^" 

24.  for  i  =  n  downto  1  do 

25.  resource{i)  r{i,pi,p2) 

26.  u{i)  :=v{i,pi,p2) 

27.  ipi,P2)  ■=  {Pi,P2) -resour ce{i) 

28.  return  v{n,  Pi,  P2),  qos{n,  Pi,  P2),  resource(l),  . . . ,  resource{n), 

m(1),  u{2)  -  ^(1),  . . . ,  u{n)  —  u{n  -  1) 
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Upon  the  return  of  the  algorithm  mrmd,  qos{n,  Pi,  P2)  will  contain  the  QoS  values 
assigned  to  Ti  through  r„,  utility(i)  contains  the  corresponding  utility  accrued  for 
Ti,  and  resour ce{i)  gives  the  resource  allocation  for  T^.  Notice  that  the  resource  part 
in  each  element  of  the  Ci  list  above  is  a  vector,  and  therefore  they  do  not  necessarily 
increase  in  the  resource  component. 

Let  L  =  max”_^  \^i\-  The  computational  complexity  of  the  algorithm  is  then  given 
by  0{nLPiP2),  or  0{nP^P^),  which  is  pseudo-polynomial  as  in  the  SRMD  case. 

The  above  algorithm  extends  in  straightforward  fashion  to  m  resources  with  com¬ 
putational  complexity  0(nPf  •  •  •  P^),  where  m  is  the  number  of  different  resources 
available  for  allocation.  Due  to  its  pseudo-polynomial  complexity,  we  expect  that 
it  will  have  limited  use  for  large-sized  on-line  systems.  However,  it  can  be  used  for 
off-line  and  solution  quality  evaluation  of  other  heuristic  and  approximation  schemes. 


6.2  Integer  Programming 

Using  the  problem  formulation  given  in  Equation  4.1  of  Section  4.2,  Integer  Pro¬ 
gramming  (IP)  algorithms  can  also  be  applied.  For  efficiency  reasons,  we  use  the 
CPLEX  [10]  MIP  callable  library  which  employs  a  branch-and-bound  algorithm.  In 
the  branch-and-bound  method,  a  series  of  linear  programming  (LP)  subproblems  is 
solved.  A  tree  of  subproblems  is  built,  where  each  subproblem  is  a  node  of  the  tree. 
The  root  node  is  the  LP  relaxation  of  the  original  IP  problem. 

To  improve  the  performance  of  the  integer  programming  with  branch-and-bound 
approach,  one  can  use  task  priorities  and  gradients  of  the  dimension-wise  quality 
utility  functions  as  heuristics  for  developing  an  integer  solution  at  the  root  node 
and  for  selecting  the  branching  node,  the  variable  and  direction.  By  setting  the 
optimality  tolerance  (such  as  the  gap  between  the  best  result  and  utility  of  the  best 
node  remaining)  or  setting  limits  on  time,  nodes,  memory,  etc.,  one  can  also  obtain 
fast  approximately  optimal  results. 

One  drawback  of  the  branch-and-bound  technique  for  solving  integer  programming 
problems  is  that  the  solution  process  can  continue  long  after  the  optimal  solution  has 
been  found,  while  the  tree  is  exhaustively  searched  in  an  effort  to  guarantee  that  the 
current  feasible  integer  solution  is  indeed  optimal.  As  we  know,  the  branch-and-bound 
tree  may  be  as  large  as  2”  nodes,  where  n  equals  the  number  of  binary  variables.  A 
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problem  containing  only  30  variables  could  produce  a  tree  having  over  one  billion 
nodes. 

We  shall  provide  a  performance  evaluation  of  this  scheme  in  the  next  chapter.  Its 
applicability  for  practical  but  large  MRMD  problems  is  yet  to  be  determined. 


6.3  An  Approximation  Scheme 

In  this  section,  we  shall  define  an  algorithm  that  yields  near-optimal  results  but  can 
execute  at  much  higher  speeds  than  the  optimal  algorithms  using  dynamic  program¬ 
ming  or  mixed  integer  programming.  We  shall  use  an  algorithm  that  uses  a  local 
search  technique.  Recall  that  n  denotes  the  number  of  tasks  and  m  denotes  the 
number  of  resources.  Let 


represent  the  discrete  set  of  utility-resource  pairs  for  task  Tj.  Note  that  in  contrast 
with  the  SRMD  algorithms  presented  in  Chapter  5  and  [27]  where  each  Vij,  I  <  j  <  h 
was  a  scalar,  the  resource  components,  r^,  in  Ci  are  vectors. 

To  handle  the  multi-dimensional  resource  case,  it  is  useful  to  define  a  penalty 
vector  to  “price”  each  resource  combination.  Specifically,  let  p  =  (pi,  •  •  •  ,Pm),  where 
Pi  €  [l,oo)  be  the  penalty  factor,  and  Vp  =  (ri  •  pi,  •  •  •  ,r,„  ‘Pm)  be  the  penalized 
resource  vector.  It  is  useful  to  define  a  scalar  metric  for  each  penalized  resource 
vector.  This  metric  is  denoted  r*.  A  variety  of  metrics  could  be  used.  For  example, 
r*  can  be  defined  as: 

r*  =  Ikpll  =  \l iXp^f  +  -  ■  +  {rpj"^ 

The  notion  of  this  virtual  or  compound  resource  can  be  thought  of  as  either  the  length 
operator  in  a  space  scaled  by  p,  or  as  similar  to  aggregate  resource  concept  described 
in  [58]. 

Once  we  have  defined  r*,  we  augment  Ci  by  adding  this  component  to  obtain: 
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We  now  define  the  algorithm  amrmdl.  In  this  algorithm,  denotes  the  current  re¬ 
maining  resource  capacity  after  some  of  the  available  resources  have  been  allocated. 
sJist[i].t,  sJist[i].r,  sJist[i].u  contain  task  ids,  their  associated  r-values  and  w-values 
of  the  corresponding  tasks,  and  r[i]  gives  the  resources  currently  allocated  to  7^-. 

amrmdl(n,  Ci, . . . ,  e) 

1.  u*  :=  0 


2. 

p  :=  initial-penalty  (Ci, 

....,Cn,r’^n 

3. 

repeat  :=  true]  count  :=  3 

4. 

while  repeat  and  count  >  0  do 

5. 

repeat  :=  false]  count  := 

■■  count  —  1 

6. 

for  i  =  1  to  n  do 

7. 

Cic  :=  compound-resource  (Q,p) 

8. 

for  i  =  1  to  n  do 

9. 

Cj'g  :=  convex-hull-frontier  {Cic) 

10. 

r[i]  :=  0 

/ /  vector  assignment 

11. 

w[i]  :=  0 

12. 

stpp[i\  :=  0 

13. 

s-list—  merge(C'{c, . . . , 

CL) 

14. 

J.C  y^max 

15. 

for  j  =  1  to  \sJist\  do 

16. 

i  :=  sJist[j].t 

17. 

if  {stop[i])  then 

18. 

break 

19. 

(3  :=  sJist[j].r  —  r[i\ 

/ /  vector  subtraction 

20. 

if  {(3  <  r^)  then 

1 

21. 

r""  :=r^  -  (3 

22. 

r[z]  ;=  sJist[j].r 

23. 

w[f]  :=  sJist[j].u 

/ /  update  allocation  of  Ti 

24. 

else 

25. 

stop[i]  :=  1 

26. 

tt  :=  0 

27. 

for  f  =  1  to  n  do 
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28.  w:=«  +  it*[i] 

29.  if  ((w  -  u*)  >  e)  then 

30.  repeat  :=  true 

31.  u*  ■.=  u 

32.  for  i  =  1  to  n  do 

33.  u*[i\  ■.=  u[i\ 

34.  r*[i]:=r[i] 

35.  p  :=  adjust -penalty  (p,  r®, 

36.  for  i  =  1  to  n  do 

37.  q[i]  hi{r*[i\)  //  see  Equation  (4.5) 

38.  return  u*,  g[l], . . . ,  g[n],  r*[l], . . . ,  r*[i] 

Note  that  the  procedure  convexJiulLfrontier  works  on  the  virtual  resource  portion  of 
each  element  in  Cic- 

The  procedure  intitiaLpenalty  calculates  the  intial  penalty  vector  by  looking  at 
the  resource  usage  pattern  of  all  task  profiles.  Resource  dimensions  in  higher  demand 
are  assigned  higher  penalties. 

initial-penalty  (n,  Ci,...,  Cn,  r”'^^) 

1.  m  :=  dimr™^ 

2.  rs  :=  0 

3.  for  i  =  1  to  n  do 

4.  for  j  =  1  to  \Ci\  do 

5.  rs  :=  rs-\-Ci{j].r  /*  vector  addition  */ 

6.  for  /c  =  1  to  m  do 

7.  pk  :=  rsk/rf^^  +  1 

8.  return  p 

The  procedure  adjust^penalty  updates  the  penalty  vector  using  information  about 
the  residual  resources  from  the  previous  iteration. 

adjust_penalty(p,  r'=, 

1.  m:=dimr“^’^ 

2.  for  fc  =  1  to  m  do 
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3.  pk  (pk  *  +  r“^)  +  1 

4.  return  p 

Many  different  formulas  could  have  been  used  here.  The  key  to  understanding  the 
one  used  above  is  write  the  formula  as 

^max 

-  ^  “Pk  “1“  1 

I  ~max  ' 

where  the  scale  factor  applied  to  pk  is  a  number  between  1/2  and  1.  The  factor  will 
be  1/2  when  the  resource  is  completely  unused  and  grows  to  1  when  the  resource  is 
used  up. 

By  setting  e  in  amrmdl  to  different  values,  along  with  the  heuristic  result  from 
procedure  initiaLpenalty  and  adjustjpenalty,  we  can  control  the  solution  refinement 
steps.  The  asymptotic  computational  complexity  of  amrmdl  can  be  obtained  as  fol¬ 
lows.  Let  L  =  max^i  |Ci|.  The  procedure  initiaLpenalty  takes  0{nL)  operations. 
After  the  procedure  convex-hulLfrontier^  (which  requires  0{nL  log  L)  operations)  a 
convex  hull  frontier  with  non-increasing  slope  segments  is  obtained  for  each  task.  The 
segments  are  merged  at  step  13  using  a  divide-and-conquer  approach  with  log2  n  levels, 
with  each  level  requiring  nL  comparisons.  Merging  thus  requires  0{nL  log  n)  opera¬ 
tions.  Steps  15  through  25  require  0(|sJist|)  =  0{nL).  The  adjusLpenalty  procedure 
requires  0(m),  and  steps  27  through  35,  36  through  38  require  0(nL).  The  total  run¬ 
ning  time  of  the  algorithm  is,  therefore,  0{nL  log  L)  +  0{nL  log  n)  -f  0{nL)  +  0{m)  = 
0{nL  log  nL  +  m). 


6.4  Related  Work 

Our  MRMD  problem  can  be  recast  as  a  multidimensional  multiple-choice  knapsack 
problem  (MMKP )  described  in  [38] .  The  authors  of  [38]  describe  a  heuristic  algorithm 
using  the  Lagrange  multiplier  technique  for  solving  MMKP  with  a  complexity  of 
0{m{n  -  gf  -h  mn)  in  their  notation.  It  corresponds  to  0{m{nL  -  +  mnL)  or 

0{mn‘^L^)  in  our  notation,  as  their  m,  n  and  g  correspond  to  our  m,  nL  and  n 
respectively. 


^  Overmars  &  Leeuwen’s  [42]  algorithm,  the  quickhull  [45]  or  Graham-Scan  [7]. 
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The  author  in  [22]  treats  the  MRSD  problem  (without  resource  tradeoff)  using 
a  heuristic  algorithm  based  on  [58].  It  is  basically  a  greedy  scheme  making  each 
step  based  on  current  resource  consumption.  The  algorithm  also  has  a  complexity  of 
0{mn^L^). 

Our  algorithm  described  in  Section  6.3  is  based  on  convex^hulLfrontier  approx¬ 
imation  combined  with  a  search  scheme  that  can  be  viewed  as  an  extended  local 
search. 

Comparing  the  approximation  algorithms  in  [38]  and  [22]  to  ours,  we  notice  that 
our  algorithm  has  a  significantly  lower  asymptotic  complexity,  0{nL  log  nL  +  m) 
versus  0{mn^L'^).  As  we  shall  see  in  Chapter  7,  this  has  been  achieved  without 
sacrificing  solution  quality.  As  a  consequence,  we  have  been  able  to  work  with  much 
larger  workloads. 


6.5  Chapter  Summary 

This  chapter  studied  solutions  to  the  MRMD  (Multiple  Resource  Multiple  QoS  Di¬ 
mensions)  problem.  As  in  Chapter  5,  dynamic  programming  is  used  to  obtain  the 
optimal  solution  to  this  problem.  Only  the  case  for  two  resources  is  presented,  but 
the  same  methodology  can  be  used  in  higher  dimensions. 

Next,  integer  programming  is  used  to  solve  the  problem  by  representing  each 
resource  trade-off,  each  QoS  tradeoff  and  the  admission  of  each  task  as  an  integer 
(boolean,  in  fact)  variable.  If  the  integer  programming  formulation  is  allowed  to 
run  to  completion,  it  will  also  yield  the  optimal  solution.  However,  since  that  can 
be  computationally  intensive,  it  may  be  terminated  when  a  execution-time-bound 
and/or  an  error-bound  is  reached.  In  this  case,  only  an  approximate  solution  will 
result. 

Finally,  a  local  search  technique  is  used  to  combine  the  various  resources  needed 
by  a  task  into  a  single  virtual  resomce.  Then,  an  optimization  technique  similar  to 
the  convex  hull  frontier  technique  from  the  previous  chapter  is  performed  on  this 
virtual  resource.  This  search  technique,  therefore,  is  computationally  very  efficient. 

In  the  following  chapter,  we  will  study  the  practical  performance  of  these  algo¬ 
rithms. 


Chapter  7 

Performance  Evaluation 


The  ideal  way  to  evaluate  the  performance  of  our  QoS  management  optimization  sys¬ 
tem  would  be  to  subject  it  to  acutal  loads  from  large  portfolios  of  real  applications. 
Such  an  approach  would  not  work  given  the  current  scarcity  of  QoS-aware  applica¬ 
tions.  Therefore,  we  have  chosen  to  evaluate  the  effectiveness  of  our  optimization 
algorithms  by  creating  a  synthetic,  but  broad,  collection  of  task  profiles  that  are  well 
beyond  the  limits  that  a  few  real  applications  can  provide.  Note  that  the  task  profiles 
that  we  have  used  for  evaluation  were  not  created  completely  arbitrarily,  but  chosen 
to  cover  the  spectrum  into  which  real  applications  would  fall  or  likely  exhibit. 


7.1  Experimental  Design  —  Task  Profile  Charac¬ 
terization 

Assume  now  that  the  number  of  tasks,  which  we  will  subject  our  system  to,  is  n. 
Assume  further,  that  the  maximum  available  resource,  is  known.  With  this 

knowledge,  the  construction  of  a  test  case  consists  of  constructing  n  task  profiles. 
These  task  are  created  independently  to  represent  different  applications. 

The  set  of  possible  task  profiles  is  infinite,  we  cannot  exhaustively  test  them  all. 
We  will  therefore  work  with  selected  representative  cases.  We  have  chosen  to  select 
the  representative  cases  randomly.  However,  care  must  be  taken  to  ensure  that  the 
produced  task  profiles  really  are  representative  of  what  applications  exhibit  and  that 
they  are  rational.  By  rational  we  mean  that 
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•  the  application  utility  function  is  non-negative  and  non-decreasing  as  a  function 
of  quality,  and 

•  quality  is  non-decreasing  with  respect  to  resources,  that  is  r  |=j  g  respects  the 
partial  orderings  of  R  and  Q  as  defined  in  Section  2.4. 

It  is  relatively  simple  to  arrange  for  the  former  condition  to  be  satisfied,  but  the  latter 
requires  much  more  attention. 

In  the  following  two  sections,  we  will  describe  in  detail  how  we  create  the  two 
parts  of  a  task  profile,  and  how  we  preserve  the  two  rationality  properties  above. 


7.1.1  QoS  Profile 

Recall  that  a  QoS  profile  consists  of 

•  Quality  indices  —  Qij,  1  <  j  <  di. 

•  Quality  space  —  Qi  =  Qn  x  ■  ■  ■  x  Qi^^. 

•  Application  utility  Ui  :  Qi  IR  which  we  define  as  a  weighted  sum  of  dimen¬ 
sional  utility  functions,  Uij  :  Qij  IR: 

di 

^i{Qi)  ~  ^  WiiUji (qh) 

i=i 


Assume  that  the  largest  point  G  Qi  has  been  given.  This  point  uniquely 

identifies  the  quality  indices  and  the  quality  spalce.  This  leaves  us  with  the  application 
utility. 

The  weights  are  generated  in  the  following  way.  Given  di,  the  number  of  quality 
dimensions  of  Tj,  we  will  generate  di  real  numbers  w'l, . . . ,  each  of  them  in  the 
range  of  [0, 1] .  Each  weight  can  then  be  obtained  as 


w: 


Wij  — 


V 


Wij 


and  these  weights  will  sum  up  to  1. 

The  requirement  that  Ui  be  non-decreasing  in  all  di  arguments  and  that  it  be  non¬ 
negative  can  be  satisfied  by  enforcing  similar  requirements  for  the  dimensional  utility 
functions. 
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The  dimensional  utilities  of  each  task  are  generated  using  the  methods  outlined 
in  Chapter  3,  that  is  using  the  same  QoS  specification  interface  structure  that  we 
envision  the  end  user  would  use.  Specifically,  we  create  a  pool  of  typical  utility 
function  shapes  as  in  Figure  3.3  in  Section  3.2.  In  other  words,  we  have  a  pool  of 
parameterized  function  classes  —  templates  that  when  properly  instantiated  will  yield 
a  dimensional  utility  function.  Example  classes  include,  but  are  not  limited  to: 


Aflftne  utility  with  saturation  and  minimum,  as  is  illustrated  in  Figure  7.1.  The 
most  general  is  on  the  right,  where  utility  remains  zero  until  a  certain  minimum 
quality,  po,  has  been  reached.  At  that  point,  utility  p2  is  gained,  and  utility  increases 
linearly  with  quality  until  it  saturates  at  pi.  This  class  of  utility  function  describes 


Utility  Utility  Utility 


caseO :  p0=p2=0 


easel:  pl=qpiax,  p2=0 


case2 :  general-case 


Figure  7.1:  Affine  Function  Class 


a  “the  more,  the  better”  type  of  quality,  such  as  the  one  for  cryptographic  security 
level  in  the  example  of  Section  3.4. 

Step-function  utility  a  series  of  quality  and  utility  pairs,  as  illustrated  in  Fig¬ 
ure  7.2.  This  class  of  utility  function  also  describes  “the  more,  the  better”  type  of 
quality  but  in  a  manner  well-suited  for  dimensions  (the  original  dimensions,  not  the 
indices)  that  are  of  non-numeric  nature  and  dimensions  for  which  the  size  of  the  index 
set  is  relatively  small. 

Exponential  Decay  where  the  difference  between  100%  and  the  achieved  utility 
decreases  exponentially,  as  illustrated  in  Figure  7.3.  This  type  of  utility  we  imagine 
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Utility 


being  used  for  quality  dimensions  with  a  diminishing-returns  behavior,  such  as  frame 
rate.  The  utility  gain  between  5fps  and  lOfps  is  much  larger  than  between  25fps 
and  30fps. 


7. 1.1.1  Function  Class  Creation 


For  the  Affine  Function  Class:  we  can  define  a  general  function 


0 

~^*(<l-P0)+P2 

1 


i{q  <Pq 
if  Po  <  g  <  Pi 


if  9  >  Pi 


where  po  and  pi  are  quality  indices  or  zero  for  which  0  <  po  <  Pi  <  and 

P2  ^  [0, 1] .  The  dimensional  utility  reaches  100%  at  quality  index  point  pi . 

Note  that  case  0  and  case  1  in  Figure  7.1  are  two  degenerate  cases  of  affine  function 
classes,  in  which  po  =  P2  =  0  for  case  0  whereas  pi  =  and  P2  =  0  for  case  1. 

For  the  Step  Function  Class:  we  have 


u{q)  = 


( 


< 


0 

P2i+1 

1 


if  9  <  Po 

if  P2i<q<  P2i+2, 
if  q>  q’^^ 


where  p2i  are  quality  indices  or  zero,  and  P2i+i  €  [0, 1],  both  strictly  increasing  with 
respect  to  their  subscripts. 
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0  1—1 — ^ ' - ■ - ■ - ■ - 1 

0  5  10  15  20  25  30 

Frame  Rate  (fps) 


Figure  7.3:  Exponential  Decay  Function  Class 


For  ExponentieJ  Decay:  we  have 

,  ,  f  0  if  9  <  9™“ 

HQ)  =  ■( 

^  1  _  eP0»9+Pl  if  ^ 

where  po  and  pi  are  real  numbers  (not  necessarily  positive).  To  make  u{q)  non¬ 
decreasing,  we  need  to  have  po  <  0.  Further,  in  order  to  have  0  <  u{q)  <  1,  we  need 
to  ensure  that  <  1,  therefore  po  *  q  +  Pi  <  0.  That  is,  pi  <  -{po*  q)  for  all 

q  €  which  is  equivalent  to  requiring  pi  <  —{po*  that  is  pi  <  —po- 

Now  we  can  describe  the  algorithm  that  creates  the  function  classes  for  QoS  pro¬ 
files. 

F(j,  /*  generate  function  for  QoS  dimension  j  with  Qij  =  {!,...,  qij°^}  */ 

1.  F.  class  :=  random-choice  {Affine,  Step,...,  ExponentialJDecay) 

2.  switch  (F.class) 

3.  case  Affine: 

4.  subtype  :=  random-int  (0,2)  /*  favor  the  3  cases  equally  */ 

5.  switch  {subtype)  /*  set  the  corresponding po,pi  and  p2  */ 

6.  case  0: 

7.  F.po:=0 

8.  F.pi  :=  random-int  (0, 

9.  F.p2  :=  0 

10.  break 
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11.  case  1: 

12.  F.po  :=  random Jnt 

13.  ■  F.pi:=q^^^ 

14.  F.p2  :=  0 

15.  break 

16.  case  2: 

17.  a  :=  random Jnt 

18.  repeat 

19.  b  :=  random Jnt  {l,q^^) 

20.  until  a^b 

21.  F.po  :=mm{a,b) 

22.  F.pi  :=  max(a,  b) 

23.  F.p2  :=  random-real  (0, 1) 

24.  break 

25.  case  Step: 

26.  if  q^^  =  1  then  /*  binary  function  */ 

27.  F.num-param  :=  1 

28.  F.po  :=  1 

29.  else 

30.  numsteps  :=  random.int  (0,  —  1) 

31.  F.num-param  :=  2  *  numstep  +  1 

32.  Li  :=  [  ] 

33.  repeat 

34.  i  :=  random -int  {l,q^^'^) 

35.  if  i  ^  Li  then 

36.  Li  :=  jLi  concat  [i] 

37.  until  \Li\  —  numstep  + 1 

38.  Li  :=  sort  {Lf) 

39.  L2  :=  [  ] 

40.  repeat 

41.  r  :=  random-real  (0, 1) 

42.  if  r  ^  1,2  then 

43.  L2  L2  concat  [r] 
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44.  until  1 1/2 1  =  numstep 

45.  L2  :=  sort  {L2) 

46.  for  i  =  0  to  num.step  —  1  do 

47.  F.p2i  :=  Li{i\ 

48.  F.p2i+i  := 

49.  ^•P2*num-step 

50.  break 

51.  case  ...  :  /*  other  function  classes  */ 

52.  : 

53.  i 

54.  case  ExponentialJDecay: 

55.  F.num-param  :=  2 

56.  F.po  :=  random-real  {—1,0) 

57.  repeat 

58.  F.pi  :=  random-real  (0, 1) 

59.  until  F.pi  <  —F.po 

60.  break 

61.  return  F 

Given  a  utility  function  F  which  was  instantiated  from  some  class,  the  QoS  dimen¬ 
sion  j  and  the  quality  index  €  Qij,  we  can  now  calculate  the  dimensional  utility 
value  of  Ti  on  qij. 

F::fv{qij) 

1.  switch  {F.  class) 

2.  case  Affine: 

3.  if  qij  <  F.po  then 

4.  rfv  :=  0 

5.  else  if  qij  <  F.pi  then 

6.  rfv  :=  (1  —  F.P2)/ {F.pi  —  F.po)  *  {qij  —  F.po)  +  F .p2 

7.  else 

8.  rfv  :=  1 

9.  break 
10.  case  Step: 
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11.  if  qij  <  F.po  tiiGii 

12.  rjv:=0 

13.  else 

14.  rfv:=  1 

15.  for  i  =  2  to  F.num-param  step  2 

16.  if  Qij  th0n 

17.  rfv  :=  F.pi^i 

18.  break 

19.  break 

20.  case  . . .  :  /*  other  function  classes  */ 

21.  ! 

22.  ; 

23.  case  ExponentialJDecay: 

24.  cfv  1  —  ^^■po*Qij~^F.pi 

25.  break 

26.  return  rfv 

7.1.2  Resource  Profile 

A  resource  profile  is  much  more  diflicult  to  create  than  QoS  Profile.  In  the  context  of 
the  resource  profiles  of  our  QoS  management  model,  a  resource  profile  is  representative 
and  rational  means  that  we  must  ensure: 

1.  Resource  usage  is  non-negative; 

2.  Resource  profiles  exhibit  resource  trade-off;  and 

3.  Higher  resource  consumption  will  not  result  in  lower  quality. 

Enforcing  the  first  property  is  trivial;  the  second,  as  will  be  shown  shortly,  will  be 
satisfied  by  the  construction  scheme  that  we  use;  the  last  property,  however,  is  initially 
challenging,  but  we  will  prove  that  it  follows  from  the  second  property  when  combined 
with  some  reasonable  assumptions. 

Before  we  devise  the  resource  profile  generation  algorithm  to  satisfy  these  condi¬ 
tions,  let  us  introduce  some  symbols  and  notations  that  will  help  to  formulate  and 
validate  the  steps  taken  to  fulfil  the  properties  imposed  on  the  typical  resource  profiles. 
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We  shall  assume  the  resource  tradeoff  comes  from  the  use  of  a  set  of  schemes 
programmed  within  an  application.  Let  Nxi  represent  the  number  of  resource  tradeoff 
schemes  for  a  Denote  by  fij  :  Qi  R,  where  j  —  the  resource 

usage  function  in  effect  when  task  T*  is  using  scheme  j.  Define  fijk  =  o  /y-  the 
resource  usages  on  m  individual  resources  respectively  using  trade-off  scheme  j,  where 
j  =  1, . . . ,  Nxi,  k  =  1, . . . ,  m,  and  is  the  projection  of  the  resource  space  into  its 
fcth  dimension. 

For  practical  reasons,  we  will  assume  Nxf  =  2  from  now  on.  That  is,  there  will 
be  two  ways  of  trading  off  resources  to  realize  a  task’s  quality  space.  In  other  words, 
for  any  given  q  E  Qi,  we  will  have  two  data  points,  {q,r)  and  {q,r'),  that  describe 
the  usage  of  m  resources  to  realize  each  quality  point.  Therefore  the  resource  profile 
r\=^iqoi  task  Tj  could  be  described  as: 

t'\=iq.  =  {(?)  faio))  I  9  ^  Qi}  ^  {(^5  fi2iQ))  I  Q  €  Qi} 

=  [J  {iQjii{Q))AQJM)} 

=  U  {{QAfmiQ)^---Ji-im{q))),{q,{fi2i{Q),---Ji2m{q)))} 

g€Qi 

With  these  notations,  we  can  now  formalize  the  three  properties  above  as  conditions 
on  the  individual  functions  fij  or  o  fif. 

Vg,i  : /ij(9)  >  0  (7.1) 

Vg  e  Qu  3s,  ^  :  ifiuiq)  >  fi2s{q))  a  {fmiq)  <  fi2t{q))  (7.2) 

yqs,qt  €  Qi  ■  Vii,i2  :  ifijiiqs)  >  fijM)  ^  "-(^s  <  9t)  (7-3) 

We  call  a  resource  profile  r  \=i  q  rational  if  it  satisfies  condition  (7.3).  Note  that 
many  of  the  above  comparisons  (“>”,  “>”  and  “<”)  in  (7.1)  through  (7.3)  are  between 
vectors,  not  simple  numbers.  For  example,  -i{qs  <  qt)  means  that  either  g*  and  qt 
are  not  comparable,  or  qa  is  bigger  than  or  equal  to  qt.  That  is,  ->{qs  <  qt)  is  not  the 
same  as  qg  >  qt-  The  comparisons  on  fijk  in  condition  (7.2),  on  the  other  hand,  are 
scalar. 

Theorem  4  r  \=iqis  rational  if  fijk  are  non- decreasing  and  satisfy  condition  (7.2). 
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Proof  Let  Qs  and  qt  be  given.  We  will  consider  three  cases: 

Case  1:  If  the  two  quality  points  Qs  and  qt  are  not  comparable,  then  qg  <  qt  is 
false,  so  -i(gs  <  qt)  is  true  and  condition  (7.3)  is  satisfied. 

Case  2:  If  the  two  quality  points  and  qt  are  equal,  then  condition  (7.3)  is  trivially 
satisfied. 

Case  3:  Assume  that  two  quality  points  qg  and  qt  are  comparable,  but  not 
equal.  Without  loss  of  generality  let  us  assume  that  g^  <  qt.  We  need  to  prove 
that  -‘{fijiiqs)  >  fij2{Qt)),  i-e.  either  (a)  fijiiqs)  and  are  not  comparable  or 

(b)  fijiiQs)  <  fmiQt)-  We  will  prove  this  by  contradiction.  Assume  that  fij^{qs)  > 
fin  (Qt) ,  where  ji ,  ^2  e  { 1 , 2} . 

Since  fijk  are  non-decreasing  functions, 

qs-)qt  •  (qs  ^  qt)  ^  (fijk(Qs)  ^  fijkiQt)) 

which  is  the  same  as 

'^i,j,Qs,qt  :  (Qs  <  Qt)  ^  (V/j :  fijkiQs)  <  fijkiQt)) 

that  is, 

'^i,j,Qs,Qt  :  (Qs  <  Qt)  (fijiQs)  <  fijiQt)) 

Therefore  we  have  fijiiQs)  <  fmiQt)-  Together  with  our  assumption,  fij^(qs)  > 
fij2  (qt),  this  means  that  fijiiQs)  ^  fij2  (Qs)- 

From  this,  we  first  conclude  that  ji  ^  j2  and  that  one  of  them  thus  is  1  while  the 
other  is  2.  Then,  from  condition  (7.2),  we  conclude  that  /ii(gs)  and  fi2(qs)  are  non¬ 
comparable  —  a  contradiction  to  fijiiqs)  >  fij2iqt)-  Our  assumption  must  therefore 
be  false,  and  the  rational  condition  (7.3)  for  r  \=i  q  holds.  □ 

Given  the  above  proposition,  we  are  ready  to  construct  the  algorithm  for  proper 
resource  profile  generation. 

Let  FC  =  {Fi,  F2, ...}  be  the  function  class  set  with  a  finite  number  of  elements, 
Nci  be  the  number  of  coefficient  for  Fj.  Let  CEijJ  =  1, . . . ,  Aq  be  the  domain  set 
for  the  jth  coefficient  of  Ft,  CEi  be  the  set  of  CEij,  and  CE  be  the  set  of  CEi,  and 
fi  be  the  function  with  F*  being  fully  instantiated  with  its  coefficient(s)  chosen  from 
CE. 

We  omit  the  description  of  the  creation  of  each  function  class  in  FC  here.  The 
process  is  similar  to  the  function  class  generation  in  QoS  profile  except  that  the 
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different  kind  of  function  shapes  are  created,  for  example,  exponential  instead  of 
exponential  decay,  since  when  quality  increasing  the  rate  of  resource  consumption 
often  is  not  decreasing. 

resource-profile  {FC,CE,m) 

/*  generate  vector  function  (consists  of  scalar  functions  fijk)  */ 

1.  for  =  1  to  2  do  { 

2.  for  A;  =  1  to  m  do  { 

3.  randomly  pick  a  function  class,  say  Fi,  from  FC 

4.  for  p  =  1  to  Nci  do 

5.  randomly  pick  the  pth  coefficient  from  CEip 

6.  let  fijk  be  the  function  with  Fi  fully  instantiated 

7.  while  -I  non.decreasing  {fijk)  do  { 

8.  p  :=  randomJnt  (1,  Nci) 

9.  replace  the  pth  coefficent  of  fijk  with  a  new  value 

10.  } 

11.  } 

12.  } 

13.  repeat  {  /*  make  sure  that  the  fij  exhibits  resource  tradeoff  */ 

14.  done-tradeoff-all  :=  true 

15.  foreach  q  E  Qi  do  { 

16.  done.tradeoff-one  :=  false 

17.  s  1 

18.  while  -idone-tradeoff-one  and  s  <  m  —  1  do  { 

19.  t:=s  +  l 

20.  while  -> done-tradeoff. one  and  t  <m  do  { 

21.  if  (fiisiq)  >  fi2s{q)  and  fmiq)  <  fi2t{q))  or 

ifiisiq)  <  fi2s{q)  and  fatiq)  >  fi2t{q)) 

22.  done.tradeoff-one  :=  true 

23.  f:=t  +  l 

24.  } 

25.  s  :=  s  +  1 

26. 


} 
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27. 

if  done-tradeoff -one  then  { 

28. 

done-tradeoff-all  :=  false 

29. 

break 

/*  for  each  loop  */ 

30. 

} 

31. 

} 

/*  for  each  loop  */ 

32. 

if  ->  done-tradeoff-all  then 

33. 

repeat  {  /*  might  need  to  regen  functions,  not  just  coeff  */ 

34. 

j  :=  random-int  (1, 2) 

35. 

k  :=  random-int  (l,rn) 

36. 

p  random-int  (1,  Nci) 

37. 

replace  ffjkS  pth  coefficient  with  a  new  value 

38. 

}  until  non-decreasing  (fijk) 

39.  }  until  done-tradeoff-all 

7.1.3  Sample  Task  Profile 

Below  is  the  task  profile  for  Tn,  a  randomly  picked  sample.  Tn  has  three  quality 
dimensions  in  concern,  and  its  and  is  (0,0,0)  and  (4,3,4)  respectively. 
Stanza  form  is  the  system  internal  representation  of  a  task  profile,  whereas  each  line 
in  the  vanilla  form  gives  the  detaildescription  on  the  utility  and  resource  consumption 
of  each  quality  point.  For  example, 

<1,1, 1>  0.507014  [<9,5>,<5,15>] 

shows  that  quality  level  (1, 1, 1)  brings  a  utility  of  0.507014.  Moreover,  the  quality 
can  be  realized  in  either  9  units  of  resource  1  and  5  units  of  resource  2,  or  5  units  of 
resource  1  and  15  units  of  resource  2.  Note  that  there  is  resource  tradeoff  between 
the  two  resources. 

Task  Profile  in  stanza  form: 


{TASK_Profile:  tid  =  11 

qmin  =  <0,0, 0>  qmax  =  <4,3,4> 

{Application_Prof ile : 

[QoS_Prof ile :  3 

[QoS_Profile_Dim:  0.3031  4  <0.7697,0. 8849, 1,1>] 
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[QoS_Profile_Dim:  0.3745  3  <0,1, 1>] 
[QoS_Profile_Dim:  0.3224  4  <0.849, 0.849,0. 849, 1>] 

] 

[Resource_Prof ile :  <4,3,4> 

[<9,5>,<5,15>] 

[<13,5>,<6,17>] 

[<17,6>,<7,19>] 

[<22,6>,<8,21>] 

[<11,5>,<5,16>] 

[<14,6>,<6,18>] 

[<19,6>,<7,20>] 

[<26,7>,<8,22>] 

[<12,6>,<5,17>] 

[<17,6>,<6,19>] 

[<22,7>,<7,21>] 

[<29,8>,<8,23>] 

[<12,6>,<5,16>] 

[<16,6>,<6,18>] 

[<21,7>,<7,20>] 

[<28,8>,<8,22>] 

[<14,6>,<5,17>] 

[<18,7>,<6,19>] 

[<24,8>,<7,21>] 

[<32,9>,<8,23>] 

[<16,7>,<5,18>] 

[<21,8>,<6,20>] 

[<27,9>,<7,22>] 

[<36,9>,<8,24>] 

[<15,7>,<6,17>] 

[<20,8>,<7,19>] 

C<26,9>,<8,21>] 

[<35,10>,<9,23>] 

[<17,8>,<6,18>] 

[<23,9>,<7,20>] 

[<30,10>,<8,22>] 
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[<40,11>,<9,24>] 

[<19,9>,<6,19>] 

[<26,10>,<7,21>] 

[<34,11>,<8,23>] 

[<45,12>,<9,25>] 

[<18,9>,<6,18>] 

[<25,10>,<7,20>] 

[<33,11>,<8,22>] 

[<43,12>,<9,24>] 

[<21,10>,<6,19>] 

[<28,11>,<7,21>] 

[<37,12>,<8,23>] 

[<49,13>,<9,25>] 

[<24,11>,<6,20>] 

[<32,12>,<7,22>] 

[<42,13>,<8,24>] 

C<56,14>,<9,26>] 

] 

} 

} 


Translated  Task  Profile  in  vainilla  form: 


<1,1, 1>  0.507014 
<1,1, 2>  0.507014 
<1,1, 3>  0.507014 
<1,1, 4>  0.555696 
<1,2, 1>  0.881514 
<1,2,2>  0.881514 
<1,2,3>  0.881514 
<1,2,4>  0.930196 
<1,3, 1>  0.881514 
<1,3,2>  0.881514 
<1,3,3>  0.881514 
<1,3,4>  0.930196 


[<9,5>,<5,15>] 

C<13,5>,<6,17>] 

[<17,6>,<7,19>] 

[<22,6>,<8,21>] 

[<11,5>,<5,16>] 

[<14,6>,<6,18>] 

[<19,6>,<7,20>] 

[<26,7>,<8,22>] 

[<12,6>,<5,17>] 

[<17,6>,<6,19>] 

[<22,7>,<7,21>] 

[<29,8>,<8,23>] 
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<2,1,1>  0.541931  [<12,6>,<5,16>] 
<2,1,2>  0.541931  [<16,6>,<6,18>] 
<2,1,3>  0.541931  [<21,7>,<7,20>] 
<2,1,4>  0.590613  [<28,8>,<8,22>] 
<2,2, 1>  0.916431  [<14,6>,<5,17>] 
<2,2,2>'0.916431  [<18,7>,<6,19>] 
<2,2,3>  0.916431  [<24,8>,<7,21>] 
<2,2,4>  0.965113  [<32,9>,<8,23>] 
<2,3, 1>  0.916431  [<16,7>,<5,18>] 
<2,3,2>  0.916431  [<21,8>,<6,20>] 
<2,3,3>  0.916431  [<27,9>,<7,22>] 
<2,3,4>  0.965113  [<36,9>,<8,24>] 
<3,1,1>  0.576818  [<15,7>,<6,17>] 
<3,1,2>  0.576818  [<20,8>,<7,19>] 
<3,1,3>  0.576818  [<26,9>,<8,21>] 
<3,1,4>  0.6255  C<35,10>,<9,23>] 
<3,2, 1>  0.951318  [<17,8>,<6,18>] 
<3,2,2>  0.951318  [<23,9>,<7,20>] 
<3,2,3>  0.951318  [<30, 10>,<8,22>] 
<3,2,4>  1  [<40,11>,<9,24>] 

<3,3, 1>  0.951318  [<19,9>,<6,19>] 
<3,3,2>  0.951318  [<26, 10>,<7,21>] 
<3,3,3>  0.951318  [<34, 11>,<8,23>] 
<3,3,4>  1  [<45,12>,<9,25>] 

<4,1,1>  0.576818  [<18,9>,<6,18>] 
<4,1,2>  0.576818  [<25, 10>,<7,20>] 
<4,1,3>  0.576818  [<33, 11>,<8,22>] 
<4,1,4>  0.6255  [<43,12>,<9,24>] 
<4,2, 1>  0.951318  [<21,10>,<6,19>] 
<4,2,2>  0.951318  [<28, 11>,<7,21>] 
<4,2,3>  0.951318  [<37,12>,<8,23>] 
<4,2,4>  1  [<49,13>,<9,25>] 

<4,3, 1>  0.951318  [<24,11>,<6,20>] 
<4,3,2>  0.951318  [<32, 12>,<7,22>] 
<4,3,3>  0.951318  [<42,13>,<8,24>] 
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<4,3,4>  1  [<56,14>,<9,26>] 


7.2  Practical  Performance  Evaluation  of  SRMD 
Algorithms 

In  Chapter  5,  we  presented  the  theoretical  behavior  of  the  SRMD  algorithms.  We 
will  now  examine  their  practical  performance.  We  compare  actual  computation  cost 
in  terms  of  running  time,  and  solution  quality  with  respect  to  optimum. 

In  our  experiments,  each  algorithm  is  fed  the  same  series  of  workloads.  The 
parameters  for  each  workload  consists  of: 

•  Number  of  tasks  (ranging  from  8  to  1024). 

•  Number  of  quality  levels  (ranging  from  8  to  128) 

•  Total  available  system  resources  (ranging  from  100  to  1000000  units) 

Note  that  the  number  of  quality  levels  is  specified  in  terms  of  utility  value,  which  is 
less  than  or  equal  to  the  number  of  quality  points.  The  point  with  the  highest  utility 
is  taken  when  the  same  resource  allocation  supports  multiple  quality  points. 

7.2.1  Comparative  Evaluation  of  asrmdl  and  srmd 

We  note  that  all  experiments  were  conducted  on  a  300  MHz  Pentium  machine  with 
192  MB  running  RedHat  Linux. 

We  now  present  a  series  of  experiments  conducted  to  compare  the  run-time  effi¬ 
ciency  and  solution  quality  of  asrmdl  relative  to  the  optimal  srmd  algorithm.  Recall 
that  the  three  main  variables  among  the  parameters  are: 

•  Number  of  tasks  (num_tasks:  ranging  from  8  to  1024). 

i 

•  Number  of  quality  levels  (quality levels:  ranging  from  8  to  128). 

•  Total  available  system  resources  (rmax:  ranging  from  100  to  1000000  units). 
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Figure  7.5:  Run  Time  and  Solution  Quality:  asrmdl  vs  srmd,  with  r’"®^=3200 
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Figure  7.6:  Run  Time  and  Solution  Quality:  asrmdl  vs  srmd,  with  r'"^''=128l 
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Alternatively,  we  could  think  of  in  terms  of  the  precision  of  the  resource 
allocation  for  the  srmd  algorithm.  When  >  100,  srmd  can  give  fractional  resource 
allocations.  For  example,  =  10000  corresponds  to  a  precision  of  one-hundredth  of 
total  capacity  or  bandwidth.  While  asrmdl  and  asrmd2  handle  non-integral  resource 
allocation  without  any  added  computational  complexity,  the  computation  time  of 
srmd  increases  as  the  granularity  of  resource  allocation  increases. 

Figures  7.4  through  7.6  present  the  run-times  of  algorithms  asrmdl  and  srmd,  and 
the  solution  quality  obtained  by  algorithm  asrmdl  relative  to  srmd,  which  represents 
the  optimal  solution.  Each  figure  presents  three  graphs  each.  The  first  and  third 
graphs  plot  the  run-times  (in  millisecond)  for  algorithms  asrmdl  and  srmd  respec¬ 
tively  as  the  number  of  tasks  in  the  system  is  increased.  The  second  graph  plots 
the  solution  quality  of  algorithm  asrmdl  relative  to  the  optimal  solution  obtained 
by  srmd.  Figure  7.4  assumes  that  r™^’'=800  and  16  QoS  options  per  task.  Simi¬ 
larly,  Figures  7.5  and  7.6  respectively  assume  =  3200,  16/32/64  QoS  levels  and 
y.max  _  1^2800,  16/32/64/128  QoS  levels.  Each  workload  in  these  experiments  was 
repeated  100  times,  each  with  numJask  number  of  different  tasks  with  random  QoS 
options  and  generated  such  that  we  could  examine  the  solution  quality  of  approxima¬ 
tion  algorithms  in  a  broad  range  of  scenarios. 

A  couple  of  behaviors  can  be  easily  observed  in  each  of  the  graphs.  The  run¬ 
times  increase  as  the  number  of  tasks  increases  (e.g.  see  Figure  7.4,  Figure  7.5,  and 
Figure  7.6  ).  The  run-times  also  increase  as  the  number  of  QoS  options  per  task 
increases.  But  notice  that  the  run-times  increase  as  the  increases  (e.g.  compare 
Figures  7.4. [be]  and  7.5. [be])  only  for  algorithm  srmd,  whereas  asrmdl  has  a  running 
time  that  is  independent  of 

Returning  to  points  of  interest,  notice  how  algorithm  asnndl  consistently  runs 
about  an  order  of  magnitude  faster  than  the  exact  algorithm  srmd  in  Figures  7.4 
through  7.6.  The  difference  approaches  two  orders  of  magnitude  when  the  granularity 
of  resource  allocation  is  finer  in  Figures  7.5  and  7.6.  Notice  further  that  the  average 
solution  quality  for  algorithm  asrmdl  in  the  second  graph  of  each  figure  stays  above 
99%  for  most  cases.  Since  the  plotted  values  axe  the  averages  over  100  runs,  the 
worst  case  obviously  is  lower.  However,  in  general,  it  is  easy  to  conclude  that  the 
approximation  algorithm  asrmdl  exhibits  excellent  behavior  in  achieving  near-optimal 
results  within  a  small  fraction  of  time  needed  to  find  the  optimal  solution. 
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Figure  7.7:  Run  Time  and  Solution  Quality:  asrmdl  vs  asrmd2  vs  srmd  with 
rma^=10000,  e  =  0.01,  and  num.qualityJevels  =  16 


7.2.2  Comparative  Evaluation  of  asrmdl  and  asrmd2 


Number  of  Tasks  Numb^  of  Tasks 


Figure  7.8:  Run  Time  and  Solution  Quality:  asrmdl  vs  asrmd2  vs  srmd  with 
rma^=100000,  £  =  0.01,  and  num_qualityJevels  =  16 


We  conducted  a  second  series  of  experiments  to  compare  the  relative  performances 
of  algorithms  asrmdl  and  asrmd2.  In  these  set  of  experiments,  we  fixed  the  number 
of  QoS  options  per  task  to  be  16  in  each  run,  and  e  was  chosen  to  be  a  constant 
0.01  (i.e.  the  desired  quality  obtained  by  asrmd2  must  be  within  1%  of  the  optimal 
solution).  The  run-times  and  solution  qualities  of  the  two  approximation  algorithms 
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Figure  7.9:  Run  Time  and  Solution  Quality:  asrmdl  vs  asrmd2  vs  srmd  with 
j,max_2QQQQQQ^  e  =  0.01,  and  num_qualityJevels  =  16 


along  with  the  optimal  srmd  algorithm  were  measured  with  =  1000,  100000  and 
1000000.  The  resulting  graphs  are  plotted  in  Figures  7.7  through  7.9  respectively.  The 
first  of  the  two  graphs  in  each  figure  plots  the  run-times  of  the  three  algorithms  as 
the  number  of  tasks  is  increased.^  The  second  graph  shows  each  algorithm’s  relative 
solution  quality  compared  to  the  optimal  solution. 

As  discussed  earlier,  algorithm  asrmd2  is  very  proniising  from  a  theoretical  point 
of  view:  it  always  delivers  a  guaranteed  solution  quality  in  polynomial  time.  Unfor¬ 
tunately,  its  actual  running  time  is  up  to  two  orders  of  magnitude  more  than  that  for 
asrmdl  (e.g.  see  Figure  7.8. a).  The  solution  quality  graphs  plot  the  solution  quality 
of  algorithms  asrmdl  and  asrmd2.  They  show  that  asrmdl  is  mostly  within  1%  of 
the  optimal  solution  while  asrmd2,  which  must  always  be  within  1%,  on  the  average 
yields  a  solution  very  close  to  the  optimal  solution.  However,  we  believe  that  the 
difference  between  the  two  run-times  is  relatively  high,  particularly  when  the  solution 
quality  obtained  by  asrmdl  is  very  good. 

Based  on  the  above  two  sets  of  experiments,  we  conclude  that  the  asrmdl  algo¬ 
rithm  using  the  convex  hull  frontier  approach  yields  the  largest  benefit  for  the  limited 
computational  time  that  it  consumes. 

It  is  practically  useful  to  note  that  in  absolute  terms,  even  with  128  tasks  and  128 


^To  keep  run-times  feasible,  the  maximum  number  of  tasks  tested  had  to  be  significantly  dropped. 
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quality  levels  per  task,  asrmdl  yields  a  near-optimal  result  in  about  20ms.  The  result 
is  also  within  0.5%  of  the  optimal  solution  on  the  average.  The  absolute  time  spent, 
20ms,  is  an  amount  of  time  that  can  be  used  in  practice  in  real-time  systems  to  make 
near-optimal  online  QoS-based  allocation. 

7.3  Practical  Performance  Evaluation  of  MRMD 
Algorithms 

In  this  section,  we  present  a  detailed  performance  evaluation  of  the  dynamic  pro¬ 
gramming  (mrmd),  integer  programming  (IP),  and  the  fast  approximation  algorithm 
(amrmdl)  discussed  in  Chapter  6. 

The  workloads  for  experiments  described  here  were  created  using  the  principles 
and  algorithms  in  Section  7.1.  < 

The  three  MRMD  algorithms  were  then  run  on  these  workloads  for  a  given  number 
of  available  units  on  each  resource.  The  running  times  and  ,  total  utility  obtained  for 
each  algorithm  were  noted.  This  was  repeated  for  several  task  sets  and  we  computed 
the  average  performance  across  these  repeated  experiments.  Finally,  for  larger  sized 
problems,  the  running  times  for  dynamic  programming  and  integer  programming 
proved  to  be  impractical  (hours  or  days  in  some  cases)  and  we  evaluated  only  the 
near-optimal  algorithm  amrmdl. 

It  must  be  added  here  that  the  optimal  results  obtained  by  the  integer  program¬ 
ming  scheme  and  the  dynamic  programming  algorithm  matched.  Fmthermore,  as 
expected,  the  approximative  algorithms  always  delivered  results  that  were  bounded 
by  the  optimal  solutions.  This  provides  us  with  a  good  degree  of  cross-validation  of 
correctness  with  respect  to  our  implementations  of  our  schemes. 

7.3.1  Performance  of  the  Dynamic  Programming  Scheme 

We  first  present  the  results  of  the  evaluation  of  the  dynamic  programming  scheme. 
As  mentioned  earlier,  dynamic  programming  yields  the  optimal  resource  allocation  to 
the  various  tasks  but  its  running  time  can  be  rather  large. 

Figure  7.10  plots  the  CPU  time  consumed  by  mrmd  (the  dynamic  programming 
algorithm)  when  there  are  two  resources  and  =  (180, 100).  In  other  words,  the 
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Figure  7.10:  The  Run  Times  of  Algorithm  mrmd  with  =  (180, 100) 


number  of  units  of  resource  1  is  180,  and  the  number  of  units  of  resource  2  is  100. 
By  assumption,  each  resource  can  only  be  allocated  in  integer  units^.  The  number 
of  tasks  to  which  these  two  resources  must  be  allocated  is  plotted  along  the  x-axis. 
The  CPU  time  consumed  by  the  dynamic  programming  scheme  is  plotted  along  the 
y-axis  and  is  in  terms  of  seconds.  Three  lines  are  plotted  corresponding  to  different 
QoS  options  available  to  each  task.  For  example,  the  top-most  line  corresponds  to  a 
QoS  maximum  of  (4, 3, 4)  (i.e.  there  are  three  QoS  dimensions,  each  having  4,  3  and 
4  discrete  options  respectively). 

As  it  can  be  seen,  the  consumed  time  increases  linearly  with  the  number  of  tasks, 
and  the  slope  increases  as  the  number  of  QoS  options  to  be  considered  increases. 
These  results  are  consistent  with  the  pseudo-polynomial  complexity  of  the  dynamic 
programming  scheme  discussed  in  Section  6.1.  Note  also  that  the  running  times  do 
not  fluctuate,  that  is  they  are  data  independent  and  very  predictable. 

It  must  be  noted  that,  in  absolute  terms,  mrmd  consumes  several  tens  of  seconds  for 
a  problem  of  modest  size  in  terms  of  the  number  of  tasks.  As  a  result,  its  applicability 
in  making  online  decisions  in  real-time  systems  is  highly  questionable  with  current 
hardware. 


^Higher  the  total  number  of  units,  finer  is  the  granularity  of  the  resource  allocation. 
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7.3.2  Performance  of  the  Integer  Programming  Scheme 


Figure  7.11:  Running  Times  for  Computing  the  Optimal  Solution  using  Mixed  Integer 
Programming 


The  CPU  time  consumed  by  the  mixed  integer  programming  package  CPLEX  on  three- 
dimension,  two-resource  problems  are  shown  in  Figure  7.11.  The  graph  plots  the 
running  times  to  find  an  optimal  solution  for  each  of  the  five  runs  of  different  sizes. 
The  results  are  shown  as  a  scatter-plot  rather  than  as  an  average  of  running  times 
due  to  their  high  degree  of  variability.  For  example,  among  the  five  problems  with 
15  tasks  having  a  QoS  maximum  of  (4,  3,4),  the  running  times  were  0.59,  0.69,  2.43, 
2.79  and  34.91  seconds.  This  indicates  that  subtle  differences  in  the  specific  utility 
and  resource  values  of  set-points  can  drastically  increase  the  size  of  the  traversed 
search  space.  Note  that  the  distribution  of  the  running  times  has  a  heavy  tail  and 
certainly  not  normal.  Therefore  we  omit  plotting  the  traditional  two-sigma  intervals. 

Optimality  Bounds  In  order  to  reduce  the  running  times  while  still  maintaining 
high-quality  results,  an  upper  bound  for  the  deviation  from  optimality  can  be  speci¬ 
fied.  A  value  of  5%  of  this  bound,  for  example,  instructs  the  algorithm  to  teminate  as 
soon  as  it  reaches  a  solution  that  is  within  5%  of  optimum.  The  running  times  for  the 
same  problem  set  as  earlier  with  an  optimality  bound  of  5%  is  shown  in  Figure  7.12. 
By  applying  this  bound,  the  worst-case  running  time  was  reduced  to  31.85  seconds 
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Figure  7.12:  Running  Times  for  Computing  Solutions  using  Mixed  Integer  Program¬ 
ming  and  a  Specified  Maximum  Deviation  from  the  Optimal  Solution 


qmax=<3,3,3> 

qmax=<3,4,3> 

qmax=<4,3,4> 


versus  107.69  seconds  for  finding  the  optimal  solution  while  at  the  same  time  main¬ 
taining  results  which  are  very  close  to  the  optimal  solution.  The  actual  quality  of  the 
results  measured  as  a  fraction  of  the  optimal  result  is  shown  in  Figure  7.13.  All  of 
the  solutions  in  our  problem  set  were  more  than  96.95%  of  the  optimal  solution. 

Running-Time  Limits  If  a  strict  upper  bound  on  the  solution  time  is  required, 
a  time  limit  can  also  be  set.  When  the  time  limit  for  a  problem  is  reached,  the 
best  available  solution  at  that  time  is  returned.  The  solution  quality  for  a  3-second 
timeout  is  shown  in  Figure  7.14.  Even  with  this  timeout,  all  of  the  sample  problems 
completed  with  solutions  that  are  at  least  93.43%  of  the  optimal.  This  demonstrates 
that  reasonable  sized  problems  can  be  solved  using  integer  programming  techniques 
when  a  timeout  is  used. 

7.3.3  Performance  of  Local  Search  Scheme  amrmdl 

We  now  evaluate  the  performance  of  the  amrmdl  algorithm.  Figures  7.15  and  7.16 
correspond  to  the  same  set  of  tasks  used  to  plot  Figure  7.10  (i.e.  =  (180, 100), 

n  =  {5, 10, 15,20,25}). 

Figure  7.15  plots  the  ratio  of  the  solution  quality  obtained  by  amrmdl  to  the  opti- 
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Figure  7.13:  Solution  Quality  Using  Mixed  Integer  Programming  and  a  Specified 
Maximum  Deviation  from  the  Optimal  Solution 


mal  solution  obtained  by  the  mrmd  dynamic  programming  algorithm.  Two  conclusions 
are  of  immediate  interest.  The  first  is  from  Figure  7.15  and  shows  that  amrmdl  ob¬ 
tains  more  than  96%  of  the  maximum  quality  obtained  by  the  dynamic  programming 
algorithm.  The  second  conclusion  is  from  Figure  7.16  which  shows  that  the  solutions 
can  be  obtained  in  the  order  of  tens  of  milliseconds  (instead  of  tens  of  seconds  for 
mrmd).  Hence,  in  brief,  amrmdl  obtains  better  than  96%  of  the  quality  obtained  by 
mrmd  but  does  so  three  orders  of  magnitude  faster. 

We  then  used  amrmdl  to  solve  much  larger  problems  (where  mrmd  and  mixed  integer 
programming  would  take  too  long  to  be  practical).  Figure  7.17  plots  the  scalability 
of  amrmdl  with  respect  to  the  number  of  tasks  and  the  size  of  each  task’s  quality 
space.  We  used  =  (10000, 10000, 10000),  n  =  8,  16,  32,  64,  128,  256,  512,  1024, 
and  the  number  of  QoS  dimensions  ranged  from  1  through  6.  The  run  times  plotted 
along  the  y-axis  are  in  logarithmic  scale.  As  can  be  seen,  acceptable  running  times 
are  obtained  for  up  to  100  tasks.  The  running  times  scale  with  both  the  number  of 
tasks  and  the  number  of  QoS  dimensions. 

Finally,  Figure  7.18  plots  the  scalability  of  amrmdl  with  respect  to  the  number  of 
tasks  and  number  of  resources.  We  now  use  of  each  task  to  be  (3, 3, 3),  n  =  8, 
16,  32,  64,  128,  256,  512,  1024.  The  number  of  resources  ranges  from  1  through  6, 


96  Performance  Evaluation 

100 
98 

96 

94 
E 

i  92 
E. 

O 

■S  90 

t  88 

3 

o 

86 

84 

82 

80 

5  10  15  20  25  30 

Number  of  tasks 

Figure  7.14:  Solution  Quality  with  Timeouts  in  Mixed  Integer  Programming 

where  each  resource  has  a  very  large  number  of  100000  units.  As  can  be  seen,  the  run 
times  do  not  change  much  at  all  as  the  number  of  resources  increases.  The  primary 
reason  is  that  amrmdl  uses  a  compound  resource  that  combines  multiple  resources  into 
a  single  virtual  resource  to  be  allocated.  Hence,  it  scales  well  and  is  robust  with  any 
increase  in  the  number  of  resources.  The  primary  determinant  of  run  times  in  this 
case  are  the  number  of  tasks  and  quality  space  which  are  considered  for  allocation. 

7.3.4  Comparative  Evaluation  of  amrmdl  and  IP 

The  unpredictable  run  times  and  the  lack  of  scalability  to  large  problems  clearly  make 
pure  integer  programming  methods  unsuitable  for  use  in  on-line  admission  control. 
Even  with  approximation  techniques,  such  as  setting  a  timeout,  high  quality  results 
cannot  be  achieved  within  a  reasonable  amount  of  time.  By  contrast,  the  amrmdl 
algorithm  obtained  solution  quality  of  better  than  96%  of  optimal  with  a  worst-case 
execution  time  of  only  90ms  on  the  30  task  example  compared  to  solution  qualities 
of  93%  of  optimal  using  integer  programming  with  a  3  second  timeout.  In  addition, 
amrmdl  also  uses  far  less  memory  than  integer  programming  which  uses  substantial 
amounts  of  memory  as  it  searches  the  solution  space.  The  combination  of  the  faster 
running  times  and  lower  memory  consumption  make  amrmdl  far  more  suitable  for 
on-line  admission  control. 
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Figure  7.15:  Solution  Quality  obtained  by  amrmdl  with  =  (180, 100) 

7.3.5  Sample  Results 

The  following  example  consists  of  15  tasks,  an  of  (180, 100)  and  a  of  (4, 3, 4). 
Note  that  we  only  show  a  single  assigned  quality  point  for  each  task  even  though  there 
might  be  multiple  quality  points  which  consume  the  same  amount  of  resources. 

Algorithm  amrmdl: 

Task  0  :  (qid=33, q=<3, 3, l>,r=<12,7>,u=0. 897889) 

Task  1  :  (qid=21,q=<2,3,l>,r=<13,3>,u=0. 986799) 

Task  2  :  (qid=20, q=<2, 2, 4>,r=<10,9>,u=0. 635217) 

Task  3  :  (qid=0,q=<0,0,0>,r=<0,0>,u=0) 

Task  4  :  (qid=46,q=<4,3,2>,r=<26,8>,u=l) 

Task  5  :  (qid=33, q=<3, 3, l>,r=<7, 12>,u=0. 476604) 

Task  6  :  (qid=8,q=<l,2,4>,r=<ll,12>,u=0.97287) 

Task  7  :  (qid=24,q=<2,3,4>,r=<18,ll>,u=0. 950321) 

Task  8  :  (qid=9, q=<l, 3, l>,r=<18,0>,u=0. 904968) 

Task  9  :  (qid=43,q=<4, 2, 3>,r=<9,5>,u=0. 891014) 

Task  10  :  (qid=10,q=<l, 3, 2>,r=<12,2>,u=0. 963892) 

Task  11  :  (qid=5,q=<l, 2, l>,r=<ll,5>,u=0. 881512) 

Task  12  :  (qid=0,q=<0,0,0>,r=<0,0>,u=0) 

Task  13  :  (qid=37.q=<4,l.l>,r=<16,14>,u=0. 717887) 

Task  14  :  (qid=16,q=<2,l,4>,r=<17,10>,u=0. 907425) 


98  Performance  Evaluation 


Figure  7.16:  Running  Times  of  amrmdl  with  =  (180, 
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Figure  7.17:  Running  Times  of  amrmdl  with  the  number  of  resources  (m)  =  3  and 
varying  the  number  of  QoS  Dimensions. 


7.4  Chapter  Summary 

Using  extensive  simulation  studies,  this  chapter  evaluated  the  performance  of  the 
algorithms  to  solve  the  SRMD  and  MRMD  problems  from  the  previous  chapters. 
The  performance  of  an  algorithm  is  measured  both  in  terms  of  its  solution  quality 
and  its  run-time.  A  good  algorithm  must  yield  both  a  high  solution  quality  and  a 
low  run-time. 

The  workload  for  the  simulations  were  generated  using  the  principles  for  user- 
interfaces  described  in  Chapter  3.  Care  was  taken  to  ensure  that  the  workloads  were 
rational  and  that  they  exhibited  tradeoffs. 

For  the  SRMD  algorithms,  detailed  evaluations  of  the  run-times  of  the  three  algo¬ 
rithms  and  their  solution  qualities  shows  that  the  first  near-optimal  algorithm  using 
the  convex  hulls  performs  very  close  to  the  optimal  solution.  It  also  has  very  prac¬ 
tical  run-times  that  it  can  even  be  used  on-line.  For  the  MRMD  case,  as  might  be 
expected,  the  running  times  are  rather  high  for  the  dynamic  programming  and  mixed 
integer  programming.  The  adaptation  of  the  mixed  integer  programming  problem, 
however,  yields  near-optimal  results  with  (potentially)  significant  lower  running  times. 
Filially,  the  approximation  algorithm  based  on  a  local  search  technique  yields  a  solu- 
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Figure  7.18:  Running  Times  of  amrmdl  with  the  number  of  QoS  dimensions  (d)  =  3 
and  varying  the  number  of  resources 


tion  quality  that  is  less  than  4%  away  from  the  optimal  solution  but  runs  more  than 
two  orders  of  magnitude  faster.  In  addition,  the  use  of  the  “virtual  resource”  allows 
this  technique  to  be  very  scalable  and  robust  as  the  number  of  resources  required  by 
each  application  increases. 


Chapter  8 

Conclusion  and  Future  Work 


This  dissertation  has  made  some  contributions  and  opened  many  avenues  for  future 
work  on  the  management  of  quality  of  service. 


8.1  Contributions  of  the  Thesis 

The  main  contributions  of  this  thesis  include: 

An  Analytical  Framework  for  Multidimensional  QoS  Memagement 

By  introducing  the  abstraction  of  quality  index,  which  maps  qualities  to  indices  in  a 
uniform  way,  and  by  the  mathematical  modeling  of  QoS  tradeoff  and  resource  tradeoff, 
we  transformed  the  multi-dimension  QoS  management  problem  into  a  combinatorial 
optimization  problem  which  ultimately  enabled  us  to  measure  QoS  quantitatively, 
and  to  analytically  plan  and  allocate  resources.  We  proved  that  the  QoS  management 
problem  is  NP-hard. 

Our  QoS  management  scheme  goes  beyond  the  basic  QoS  scheme  of  delivering 
service  in  a  prioritized  fashion.  Instead,  our  system  allows  applications  and  users  to 
assign  values  (utilities)  to  different  levels  of  service  that  a  system  can  provide.  The 
QoS  management  optimization  module  can  then  explore  fully  the  QoS  tradeoffs  and 
resource  tradeoffs  to  make  resource  allocations  to  these  applications  so  as  to  maximize 
the  global  utility  derived  by  these  systems. 

The  global  objective  can  be  the  overall  appreciation  of  the  applications  in  the 
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system,  with  or  without  priority  enforcement,  or  the  profit  margin.  The  enhanced 
prioritized  allocation  can  prevent  greedy  users  from  cheating  the  system  and  amassing 
resources  when  accounting  is  not  in  place  for  the  services.  We  also  demonstrated  that 
the  problem  instance  associated  with  each  of  those  objectives  can  all  be  solved  with 
our  approximation  or  heuristic  schemes  without  modification  of  the  algorithms. 

QoS  and  Resource  Tradeoff 

In  coping  with  the  shortage  of  QoS  support  from  an  end-user  point  of  view,  we 
proposed  a  management  scheme  that  empowers  the  end  users  to  give  guidance  on  the 
qualities  they  care  about  and  the  tradeoffs  they  are  willing  to  make  under  potential 
resource  constraints. 

We  investigated  the  important  issues  of  QoS  tradeoff  and  resource  tradeoff  and 
demonstrated  how  they  can  be  used  in  accommodating  user  requirements  of  adaptive 
nature. 

The  notion  of  application  utility  is  used  to  quantify  the  relative  merits  of  various 
QoS  levels  or  points.  QoS  tradeoffs  can  therefore  be  made  based  on  application 
utilities. 

The  general  resource-quality  relation  t  q  for  each  task  is  a  description  of  the 
application’s  resource  usages  at  different  levels  of  quality.  The  same  quality  level  can 
be  satisfied  in  several  ways  by  making  tradeoffs  among  resources. 

QoS  Specification  Interface 

The  QoS  Specification  Interface  is  semantically  rich  both  in  terms  of  expressiveness 
and  customizability.  We  proposed  and  presented  some  user-interface  mechanisms 
to  facilitate  such  rich  specification  acquisition,  such  as  utility  templates,  saturation 
point,  satisfaction  knee  points,  and  conditional  requirement  etc.,  that  users  can  use 
to  interact  easily  with  the  system  and  to  communicate  their  sophisticated  request  to 
the  optimisation  module  efficiently. 

Synthetic  Rationed  Task  Profile  Generation 

We  developed  a  systematic  way  of  generating  synthetic  task  profiles  that  exhibit  all 
the  properties  we  expect  from  real  task  profiles,  in  particular  QoS  tradeoff,  resource 
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tradeoff,  and  that  quality  is  non-decreasing  with  respect  to  resources.  Moreover,  the 
characterization  of  task  profiles  conforms  to  user  interface  methodology  described  in 
this  thesis. 

Fast  Approximation  Algorithms 

We  have  developed  a  series  of  optimization  algorithms  that  tackle  the  QoS  manage¬ 
ment  problem. 

The  first  set  of  algorithms  treats  the  problem  of  maximizing  system  utility  by  allo¬ 
cating  a  single  finite  resource  to  satisfy  the  QoS  requirements  of  multiple  applications 
along  multiple  QoS  dimensions.  We  developed  two  near-optimal  algorithms  to  solve 
this  problem.  The  first  yields  an  allocation  within  a  known  distance  from  the  optimal 
solution,  and  the  second  yields  an  allocation  whose  distance  bound  from  the  optimal 
solution  can  be  explicitly  controlled  by  the  QoS  manager. 

The  second  set  of  algorithms  deals  with  apportioning  multiple  finite  resources  to 
satisfy  the  QoS  needs  of  multiple  applications  along  multiple  QoS  dimensions.  We 
evaluated  and  compared  three  strategies.  First,  dynamic  programming  and  mixed 
integer  programming  compute  optimal  solutions  to  this  problem  but  exhibit  very  large 
running  times.  We  then  adapted  the  mixed  integer  programming  problem  to  yield 
near-optimal  results  with  faster  running  times.  Finally,  we  present  an  approximation 
algorithm  based  on  a  local  search  technique  that  is  less  than  a  few  percent  (less  than 
4%  in  average  in  the  experimients  we  conducted)  from  the  optimal  solution  but  which 
is  more  than  two  orders  of  magnitude  faster  than  the  optimal  scheme  of  dynamic 
programming.  Perhaps  more  significantly,  the  local  search  technique  turns  out  to  be 
very  scalable  and  robust  as  the  number  of  resources  under  management  increases. 


8.2  Future  Research  Directions 

It  would  be  interesting  to  conduct  experiments  where  the  integer  programming  pack¬ 
age  is  combined  with  an  approximation  algorithm.  This,  for  example,  could  be  done 
by  giving  the  near-optimal  result  of  the  approximation  algorithm  as  a  starting  point 
to  the  integer  programming  scheme.  This  might  improve  the  already  very  good  solu¬ 
tion  quality  of  an  approximation  algorithm  with  moderate  use  of  extra  CPU  time.  In 
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addition,  parallel  algorithms  can  be  developed  to  speed  up  the  computation  process. 

In  this  thesis,  most  of  the  effort  has  been  spent  on  the  mathematical  modeling 
of  QoS  management  that  facilitates  QoS  tradeoff  and  resource  tradeoff,  developing 
practical  algorithms  for  optimization,  and  benchmarking  workload  that  characterizes 
or  represents  QoS  tradeoff  and  resource  tradeoff.  The  next  important  step  is  to 
subject  the  system  to  actual  loads  from  real  QoS-aware  applications.  This  means 
that  existing  applications  need  to  be  modified  or  new  QoS  adaptive  applications  need 
to  be  developed. 

Our  QoS  management  optimization  system  is  essentially  centralized  within  each 
domain.  When  several  such  domains  are  connected  and  thus  share  resources,  a  dis¬ 
tributed  framework  has  to  be  in  place  to  facilitate  global  QoS  management. 

This  thesis  as  well  as  [30,  27,  28]  focus  on  the  QoS  management  with  discrete 
quality  dimensions,  whereas  [46]  and  [47]  focus  on  continuous  quality  dimensions.  It 
would  be  useful  to  combine  the  two  into  a  unified  system. 


8.3  Concluding  Remarks 

We  envision  an  environment  where  many  real-time  and  non-real-time  applications 
each  with  multiple  QoS  dimensions  co-exist  in  a  system  with  a  finite  set  of  resources. 
During  loaded  periods,  the  system  may  not  have  sufficient  resources  to  deliver  the 
maximum  quality  possible  to  every  application  along  each  of  its  QoS  dimensions. 
Hence,  decisions  must  be  made  by  the  underlying  resource  manager  to  apportion 
available  resources  to  these  applications  such  that  a  global  objective  is  maximized. 
The  system  can  be  used  to  continuously  monitor  and  adjust  clients’  level  of  service  in 
light  of  the  dynamically  changing  operational  environment  of  clients  and  resources. 

Our  QoS  specification  allows  applications  and  users  to  put  values  on  the  different 
levels  of  service  that  the  system  can  provide.  When  “value”  is  taken  literally,  this 
means  that  our  model  is  able  to  facilitate  market-efficient  resource  distribution.  Such 
a  system  has  considerable  potential,  especially  in  solving  bandwidth  problems  of  the 
increasingly  crowded  Internet. 


Appendix  A 

Symbols  and  Notations 

A.l  Symbols  in  General  Use 

The  following  symbols  are  used  throughout  the  thesis: 


Symbol 

Brief  Explanation 

Page 

fij 

mapping  between  actual  quality  and  quality  indices 

h  10 

n 

number  of  tasks 

f  13 

m 

number  of  resources 

13 

di 

number  of  quality  dimensions  of  task  Ti 

13 

Ti,... 

T 

tasks  in  the  system 

13 

Ri, . . 

•  •)  Rm 

resources  for  management 

13 

Qil^  •  ■ 

•  •  5  Qidi 

dimensional  quality  space  for  Ti 

13 

R 

resource  space 

13 

^max 

maximum  amount  of  resource  for  allocation  —  a  vector 

13 

hi 

resource-quality  relation,  or  resource  profile  for  Tj 

13 

Qi,  •  • 

•  ?  Qn 

quality  space  for  task  Ti,  ..  .,Tn 

14 

Ui 

application  utility  for  T 

14 

IR 

real  numbers 

14 

^min 

minimum  quality  for  Tj  —  a  vector 

15 

^max 

maximum  quality  for  Tj  —  a  vector 

15 
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Symbol 

Brief  Explanation 

Page 

u 

system  utility  in  general 

16 

'liyj 

system  utility  —  weighted  sum  of  application  utilities 

16 

u* 

system  utility  —  minimum  utility  accrued  for  a  task 

16 

Wi 

weight  for  Ti 

16 

Uij 

dimensional  utility  of  Ti 

29 

Wij 

dimensional  utility  weight  for  Tj 

30 

9i 

best-utility  function 

41 

.  hi 

best-utility  quality  selector 

41 

.  '^k 

projection  of  the  resource  space  into  its  fcth  dimension 

77 

A.2 

Symbol_ 

Symbols  Used  for  NP-hard  Proof 

^  Brief  Explanation 

Page 

Kil  5  ...  5 

an  enumeration  of  the  quality  space 

36 

Nij 

number  of  resource  usage  choices 

36 

Pijl  ?  •  ‘  • 

1  PijNij 

an  enumeration  of  the  resource  usage  choices 

36 

^ijk 

binary  variable,  Xijk  =  1  if  task  Ti  has  been  given  quality 
point  Kij  and  resource  consumption  and  Xijk  —  0 

otherwise 

36 

n 

number  of  knapsack  items 

37 

C 

knapsack  capacity 

37 

Pi 

the  profit  of  adding  item  i 

37 

Wi 

the  weight  of  item  i 

37 

Xi 

indicator  variable  for  knapsack  item  i 

38 
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A.3  Symbols  and  Notations  Used  in  the  Algorithms 


Symbol 

Brief  Explanation 

Page 

V 

dynamic  programming  recursive  function 

43 

P 

number  of  allocation  units  in  total 

43 

P 

units  of  resource  allocated 

43 

(:) 

r-«-pair 

44 

a 

r-u-pair  list;  list  of  function  gfs  discontinuity  points 

44 

9i 

convex  hull  frontier  of  Qi 

45 

Cl 

list  of  function  g°^s  discontinuity  points 

47 

L 

maximum  length  of  Ci 

45 

Uopt 

optimal  utility 

47 

t^asrmdl 

utility  obtained  through  algorithm  asmrdl 

47 

maximum  utility  difference  between  adjacent  discontinu¬ 
ity  points  of  Cl 

47 

X 

largest  Si 

47 

C^k,srmd2 

utility  obtained  through  algorithm  asmrd2 

49 

€ 

error  bound  relative  to  optimal  result 

49 
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